用于建模的体系结构

Question

建立由多种不同类型组成的系统模型的常见解决方案是创建一个模块化系统，其中每个模块负责特定类型。例如，Wombat WombatModule模块将包含：IModule，其中IModule接口具有GetCount（）（查找若干个Wombats）和Update（）（更新所有Wombats状态）等方法。

更多面向对象的方法是为每个项目类型添加类并为每个项目创建一个实例。这将使类Wombat：IItem的方法像Update（）（更新这个wombat）。

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

问题出现在类型和模块数量增长时。要么你失去了大多数的性能优势，因为每个模块只支持几个项目，或者模块的复杂性增长，以适应一种普通类型的稍微不同的项目 - 比如胖胖的瘦子。或两者。

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

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

Answer 1

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