OOD启思录之经典语录

Arthur: J.Riel     Object-Oriented Design Heuristics

探讨对面向对象分析和设计的两种相互竞争的观点，并说明两种观点都不是整体最优的。
持第一种观点的人认为， 面向对象分析应该是一个数据驱动的过程， 在这个过程中开发者检查系统的需求、寻找关联、寻找自然聚合以及继承。系统的行为（就是使用关系）直到设计时才被指定。这种方法的理念是先创建一个完整的对象模型， 而不必卷入对行为的指定。Rumbaugh方法是数据驱动模型这一类中最流行的方法。
第二种观点则基本上是数据驱动建模的对立面。这种观点称，面向对象分析应当关注系统的行为。设计者应当在分析阶段找出类和它们之间的使用关系。在设计时，有一些使用关系被细化成包含关系。Booch、Jacobson和Weiner/Wilkerson/Wirfs-Brock是3种比较著名的行为驱动方法学。
......
在一些管理信息系统(MIS)领域，数据驱动的方法可以工作得很好。 这是因为在这些MIS应用程序中没有有意义的行为。这些应用程序所做的常常是把一个对象模型分割成一个个部分并把它们分布在各种不同的表单中。这不是说MIS应用系统不重要。很多该领域的项目都非常复杂，只是它们的行为是平凡的。所有有意义的内容就是静态的对象模型，可能还有用户界面。
......
而行为驱动的方法则具有另一个不同但等价的问题。在大型系统中会有很多类，设计者必须在分析模型中利用自然聚合。如果不考虑这些自然聚合，那么系统中的每个类都位于设计的最顶层，这会导致非常复杂的协作图（位于设计最顶层的类和它们之间的使用关系）。事实证明，试图分析这张图来找出包含关系是非常困难的。这个问题在只有15到20个类组成的小系统中是不可见的。但是如果把这个方法学用于具有200个类的系统，那么这个缺点就会浮现出来。最终我们可能把这200个类组织成15个包含层次结构。这是我检查设计时所期望的层次， 15个类而不是200个类。当然数据驱动模型受到这个事实的影响：在分析阶段，只能找出自然聚合。大多数系统也使用包含关系来在一个包含层次结构中分页系统功能。如果不把系统的行为作为指导的话，无法找出包含的这种用法。
......
既然我不仅指出了数据驱动设计的不足，还指出了行为驱动的不足，那么设计得从需求规约创建系统时应当做些什么呢？
我建议综合以上两种方法。我一开始总是使用数据驱动的建模技术，然后逐渐(epil)过渡到行为驱动的设计方法。这样我可以用自然聚合来简化设计，并且我也可以在分析阶段讨论系统的行为。我相信，一开始采用数据驱动建模肯定不会带来害处， 只要设计得能够认识到，若不讨论行为的话对于很多系统都无法创建出完整的对象模型。