建模架构
构建由许多不同类型的项目组成的系统模型的常见解决方案是创建模块化系统，其中每个模块负责特定类型。 例如，将有袋熊模块 WombatModule:IModule，其中 IModule 接口具有 GetCount()（查找袋熊数量）和 Update()（更新所有袋熊状态）等方法。
更面向对象的方法是为每个项目类型创建类并为每个项目创建一个实例。 这将使类 Wombat:IItem 具有 Update() 之类的方法（以更新这一袋熊）。
从代码的角度来看，差异可以忽略不计，但运行时却有显着差异。 面向模块的解决方案当然更快：更少的对象创建，更容易优化所有袋熊常见的操作。
当类型和模块数量增加时就会出现问题。 要么你会失去大部分性能优势，因为每个模块只支持几个项目，要么模块的复杂性会增加以适应一种通用类型的稍微不同的项目 - 例如，胖的和苗条的袋熊。 或两者。
至少有一次，当 WombatModule 所做的只是保留隐藏的 Wombat 对象的集合并循环运行它们的方法时，它会降级到较差的状态。
当性能比长期开发更不是问题时，您能否找出使用模块而不是每项对象的任何架构原因？ 也许我还缺少另一种可能性？
A common solution to building a model of a system which consists of many items of different types is to create a modular system, where each module is responsible for particular type. For example, there will be module for wombats WombatModule:IModule, where IModule interface has methods like GetCount() (to find number of wombats) and Update() (to update all wombats' state).
More object-oriented approach would be to have class for every item type and create an instance for every item. That will make class Wombat:IItem with methods like Update() (to update this one wombat).
From code perspective difference is negligible, but run-time is significantly different. Module-oriented solution is certainly faster: less object creation, easier to optimize operations common for all wombats.
Problems come when number of types and modules grow. Either you lose most of performance advantage because each module only supports several items, or modules' complexity grows to accomodate for slightly different items of one general type - say, fat and slim wombats. Or both.
At least once I've seen it degrade into poor state when all WombatModule does is keep a collection of hidden Wombat objects and run their methods in loop.
When performance is less of a problem than long-term development, can you identify any architectural reasons to use modules instead of per-item objects? May be there's another possibility I'm missing?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我在一家
嵌入式软件公司工作，我们的代码库非常大。 代码库设计有执行特定功能并维护某些对象的模块 - 也有一些对象仅作为独立对象存在。 我们的方法遇到的最大问题是区分模块的边界。 随着时间的推移，我们的模块往往会变得不必要的复杂，并慢慢地增长以执行最初超出其边界的功能。 我想说最好的方向是模块化设计并实现非常具体的对象，并努力不让模块变得比您预期的更大。I work for an
embedded software companyand ourcode baseis quite large. The code base was designed with modules that perform specific functions and maintain some objects - also some objects exist as just independent objects. The largest problem we see with our approach is distinguishing the boundaries of modules. Our modules have tended to grow unnecessarily complicated over time and slowly grow to perform functions that were originally outside of it's boundaries. I would say the best direction to take would be to design modularly and implement very specific objects and to make a dedicated effort to not let modules grow larger than you intend.