游戏的建筑模式

Question

所以我有一个包含一些大项目的解决方案，我正试图分解成更小的项目，责任更加孤立。这是一个游戏，但我主要是一个LOB开发者，我认为原则可能是普遍的，我想我可以在这里学到一些东西。

某些对象中的依赖关系有点紧密交织在一起，我希望能帮助解决它们的问题。或者某种模式或抽象可能使它们更易于管理。

Ares.Core.World 在其中有类，如Creatures，Items等。所有这些类都继承自Entity，它知道它存在于地图上的哪个单元格。它通过保持对Ares.Core.UI.MapControls.MapCell的引用来实现这一点......你可以看到线已经越过了。

Ares.Core.UI.MapControls 包含Map和MapCell，每个都包含生物列表和它们包含的项目。 MapCell也继承自Ares.Core.World.Entity，因为它非常优雅地解决了一些早期问题 - 例如，所有实体都有库存。

我想找到一种方法将UI和World拆分成单独的项目（ Ares.World 和 Ares.UI ），因为UI和整个世界应该可能是分开的担忧。但正如您所看到的，现在两个项目的方式需要相互引用，并且不允许循环引用。

我想知道是否有任何可能有助于这种情况的架构模式。谢谢！

Answer 1

所以，你的世界级 - 生物，物品等 - 他们都需要来自MapCell的某些东西。

您能合理地创建一个代表世界实体需要的界面（或几个）吗？那么实体只需要实现该接口？

这将是解耦这两者的第一步。显然，此接口的方法签名或属性都不能包含UI项目中的类。它应该在World和UI引用的库中使用标准类型或自定义类型定义（例如，Ares.Core）。

然后，在UI项目中定义封装MapCell的接口的实现，并提供World Entities所需的内容。

使用您选择的IoC在需要的地方提供实施，具体取决于您获取MapCell的方式，您可能还需要在工厂上进行分层。

如果没有更多关于您特定需求的详细信息，那么很难具体，但我认为这种方法通常应该是可行的。

Answer 2

让不同名称空间中的类在细粒度级别上进行交互没有任何问题。关注点的分离可以在访问者保护级别（公共，受保护，私有等）完成。您可以在逻辑上或结构上将项目分解为子项目，应用您认为相关的任何额外组织约束。

有些策略可能是：

• 在结构上分离逻辑，其中每个孤岛恰好位于自己建立的命名空间中，并且只通过高级接口进行交互。
• 逻辑分离，其中程序集（或一组asms）成为可能跨越多个名称空间的逻辑项目。可以通过接口完成交互，也可以通过彻底考虑成员访问来完成。

要解开它们，尝试从不同的角度看待项目。从一个POV看起来像一个完全混乱的东西实际上可以从另一个POV看起来优雅。如果你发现它们的类结构背后确实有一个合理的逻辑，那么所需要的只是开始将零碎分成不同的程序集，只需对命名空间进行微调。如果你发现它确实很混乱，那么，你的工作就会被删除:-D

Answer 3

1. Divide and Conquer设计建议您将UI和核心组件分开。
2. 您的游戏逻辑应该是核心模块的一部分，而不是UI。
3. UI应具有图形界面和动作界面或对象行为界面，并由核心模块实现。