C#委托和事件设计/体系结构

本文关键字：体系结构 事件 | 更新日期: 2023-09-27 18:29:19

场景：一个有一块木板和几个瓦片的游戏。类：木板、瓦片和玩家，当然还有游戏。每当玩家按下瓷砖时，他的分数就会增加1Board在Game中实例化，Tile的数组在Board实例化。我轻松增加分数的第一个选择是制作一个带有公共静态字段（分数）的公用静态类。当然，这相当业余。似乎打破了应用程序的整体流程。

经过一番思考，我将所有内容都改为使用Events平铺单击时引发事件Board处理该事件，并将另一个事件提升到主Game类玩家在游戏内部实例化；当Game处理从Board接收的事件时，它会执行PlayerOne（Player的实例）。得分+=1；

我应该继续使用这个流程吗？你还有其他更好的架构/设计想法吗？为什么你的想法会更好？我以前没有密集地使用定制活动，我觉得整个活动引发了另一个偶数的想法可能有点错误。然而，从远处看，它看起来像是一个良好的流动。它确实做得很好。

C#委托和事件设计/体系结构

您描述的是观察器设计模式。游戏应该"听"来自棋盘的事件，棋盘应该听来自瓦片等的事件。

您应该已经提供了一些代码。

我应该继续使用这个流程吗？

这取决于事件的样子。

你还有其他更好的架构/设计想法吗？

发布/订阅是一种选择。但是.NET事件在这里运行良好。

我以前没有密集地使用定制活动，我觉得整个活动引发了另一个偶数的想法可能有点错误。

保持封装是可以的。我会做一些类似的事情：

class Tile
{
    public event EventHandler Clicked = delegate{};
}
class Board
{
    private void OnTileClick(object source, EventArgs e)
    {
        var tile = (Tile)source;
        //doSome
        var args = new CustomEventArgs();
        CustomEvent(this, args);
    }
    public event EventHandler<CustomEventArgs> SomeEvent = delegate{};
}
public class SomeCustomEventArgs : EventArgs
{
}

脑海中浮现的唯一其他可能性是从充当回调的较高类传递/设置委托，这样较低的类就可以检查有效的委托并在不知道谁拥有它的情况下调用它。如果您将其列为可能的委托列表，则可以让多个订阅者都从该回调中受益。

话虽如此，我觉得您的活动架构非常优雅。

另一种看待它的方法是，Board依赖于Player才能正常工作。一次有多少玩家？在游戏时间里，玩家会被添加到棋盘上吗？

如果没有，你可以在创建时将玩家传给棋盘，然后棋盘可以增加玩家的分数。只要在游戏层面没有其他可能影响得分的逻辑，这就有效。

您似乎已经实现的体系结构适用于此场景。

使用observer体系结构可以方便地管理通过对象关系创建的依赖关系。

这里的观察者架构将允许您非常容易地添加或删除播放器、瓷砖和板。如果"游戏"现在需要管理多个棋盘，那么只需将对象添加到中并订阅其公开的事件，就可以优雅地管理它。这是因为瓦片不需要知道玩家的存在。就像玩家不需要知道游戏的存在一样——他们只是独立地完成自己的工作。

其他模式可能会创建不需要的依赖关系，从而导致将信息传递回链（从tile、到播放器、到游戏）所需的额外代码，这很容易在项目实现的过程中导致问题。

相关文章：