游戏的体系结构模式
本文关键字：结构模式 游戏 | 更新日期: 2023-09-27 17:56:53
所以我有一个包含几个大项目的解决方案，我试图将它们分解为具有更孤立职责的小项目。这是一款游戏，但我主要是一名 LOB 开发人员，我认为这些原则可能是通用的，我想我可以在这里学到一些东西。
某些对象中的依赖关系有点过于紧密地交织在一起，我希望在如何解开它们方面得到一些帮助。或者可能是某种模式或抽象，可能使它们更易于管理。
Ares.Core.World 里面有生物、物品等类。它们都继承自实体，实体知道它存在于地图上的哪个单元格。它通过持有对Ares.Core.UI.MapControls.MapCell的引用来实现这一点。你可以看到电线已经交叉了。
Ares.Core.UI.MapControls包含Map和MapCell，每个都包含它们所包含的生物和项目列表。MapCell也继承了Ares.Core.World.Entity，因为它非常优雅地解决了一些早期问题 - 例如，所有实体都有库存。
我想找到一种方法将UI和World拆分为单独的项目（Ares.World 和Ares.UI），因为UI和总体世界可能是单独的关注点。但正如你所看到的，现在两个项目的方式需要相互引用，并且不允许循环引用。
我想知道是否有任何架构模式在这种情况下可能会有所帮助。谢谢！
所以，你的世界职业 - 生物，物品等 - 他们都需要来自MapCell的东西。
你能合理地创建一个（或几个）接口来代表世界实体所需要的吗？ 这样实体只需要该接口的实现？
这将是使两者脱钩的第一步。 也许很明显，此接口的任何方法签名或属性都不能包含 UI 项目中的类。 它应该在库中使用的标准类型或自定义类型定义，包括世界和 UI 参考（例如，Ares.Core）。
然后，在UI项目中定义封装MapCell并向世界实体提供所需内容的接口的实现。
使用您选择的 IoC 在需要的地方提供实现，具体取决于您获取 MapCell 的方式，您可能还需要在工厂上分层。
如果没有更多关于您的特定需求的细节，很难具体，但我认为这种方法总体上应该是可行的。
让不同命名空间中的类在细粒度级别进行交互并没有错。关注点分离可以在访问器保护级别（公共、受保护、专用等）完成。您可以按逻辑或结构将项目分解为子项目，应用您认为相关的任何额外的组织约束。
一些策略可能是：
- 结构上分离逻辑，其中每个筒仓恰好驻留在自己建立的命名空间中，并且仅通过高级接口进行交互。 逻辑
- 分离，其中程序集（或一组 asm）成为可能跨越多个命名空间的逻辑项目。交互可以通过接口完成，也可以通过彻底考虑成员访问来完成。
要解开它们，请尝试从不同的角度看待项目。从一个 POV 看起来一团糟的东西实际上在另一个 POV 看起来很优雅。如果您发现它们的类结构背后确实存在合理的逻辑，也许只需要开始将位和片段分离到不同的程序集中，只需对命名空间进行微小的调整。如果你发现它真的是混乱的，那么，你的工作就为你剪掉了:-D
- 分而治之设计建议您应该将 UI 和核心组件分开。
- 游戏逻辑应该是核心模块的一部分，而不是 UI。
- UI应具有图形界面和动作界面或对象行为界面，并由核心模块实现。