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

更加面向对象的方法是为每个项目类型提供类并为每个项目创建一个实例。这将使类Wombat：IItem具有类似Update()的方法(以更新此一个袋熊)。

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

当类型和模块数量增加时，问题就来了。我们可能失去了大部分的性能优势，因为每个模块仅支持多个项目，或者模块的复杂性逐渐增加，无法适应一种普通类型(例如胖和苗条的袋熊)的略有不同的项目。或者两者。

至少当我看到所有WombatModule所做的工作是保留一组隐藏的Wombat对象并循环运行它们的方法时，它会退化为糟糕的状态。

当性能不是长期开发所要解决的问题时，我们能否确定使用模块而不是每个项目对象的任何体系结构原因？可能还有我不见了的另一种可能性吗？

解决方案

回答

我在一家嵌入式软件公司工作，我们的代码库很大。该代码库设计有执行特定功能并维护某些对象的模块，有些对象也只是独立的对象而存在。我们使用的方法遇到的最大问题是区分模块的边界。随着时间的流逝，我们的模块趋向于不必要地变得复杂，而缓慢地增长以执行最初在其边界之外的功能。我想说的最好的方向是模块化设计和实现非常具体的对象，并做出专门的努力以使模块不会超出预期。