用于建模的架构

Question

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

更面向对象的方法是为每个项目类型创建类，并为每个项目创建一个实例。这将使用像Update()这样的方法(来更新这一个袋熊)来创建类Wombat:IItem。

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

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

至少有一次我看到它降级到了糟糕的状态，而WombatModule所做的一切就是保持一个隐藏的Wombat对象的集合，并在循环中运行它们的方法。

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

Answer 1

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