建模架构

Question

构建由许多不同类型的项目组成的系统模型的常见解决方案是创建一个模块化系统，其中每个模块负责特定类型。例如，将有袋熊模块 WombatModule:IModule，其中 IModule 接口有 GetCount()（查找袋熊数量）和 Update()（更新所有袋熊状态）等方法。

更多面向对象的方法是为每个项目类型设置类并为每个项目创建一个实例。这将使类 Wombat:IItem 具有像 Update() 这样的方法（更新这个袋熊）。

从代码角度来看，差异可以忽略不计，但运行时差异很大。面向模块的解决方案当然更快：更少的对象创建，更容易优化所有袋熊通用的操作。

当类型和模块的数量增加时，问题就来了。要么你失去了大部分性能优势，因为每个模块只支持几个项目，要么模块的复杂性增加以适应一种通用类型的稍微不同的项目——比如胖袋熊和瘦袋熊。或两者兼而有之。

至少有一次我看到它退化为糟糕的状态，而 WombatModule 所做的只是保留隐藏的 Wombat 对象的集合并循环运行它们的方法。

当性能问题比长期开发问题更小时，您能找出使用模块而不是每个项目对象的任何架构原因吗？可能还有另一种可能我错过了？

Answer 1

我为embedded software company 工作，我们的code base 很大。代码库设计有执行特定功能和维护一些对象的模块——还有一些对象作为独立对象存在。我们在方法中看到的最大问题是区分模块的边界。随着时间的推移，我们的模块往往会变得不必要地复杂，并且会慢慢增长以执行最初超出其边界的功能。我想说最好的方向是模块化设计和实现非常具体的对象，并努力不让模块变得比你想要的大。