让类像珍珠一样美丽

很显然，类不是现实实体的一一映射，而是包含着大量抽象（abstraction）的结构，这个结构应当比现实中的实体来得更纯粹，更稳定，更灵活。现实中实体的职责（responsibility）可能是混杂的，甚至不清晰的，现实实体之间的dependency可能是cycle的，现实实体是不稳定的，是多变的，因而常常展现出令人吃惊的连锁反应，比如南美丛林中的那只小蝴蝶。但是软件不能是这样，更狭义的说，类，和类结构不能是这样，因为一旦这样就会在软件系统中埋下巨大的波澜。面对现实/自然的变化我们只能适应，充其量预防，而更多的是花费巨大的代价去恢复和修补。我没没办法控制现实/自然，但我们可以控制软件系统，设计出满足我们需要的世界。

 

每一个类，都应当像珍珠一样纯粹，尽量不包含瑕疵，纯白就是纯白，墨绿就是墨绿，绝不是斑点狗或者斑马。

 

只有一个职责，只为一个目的而生，只保存这个目的必须的field，只实现这个职责必须的行为。Employee只是一个职员，不要让paying行为“污染”它，交给一个helper类，它只负责paying，例如叫PaydayTransaction，但是这其中又涉及各种不同的pay schedule（有的按周，有的按月，有的按年），分出去，叫PaymentSchedule；又涉及不同的薪酬计算方法（有的就是工资，有的还有回扣，有的按小时计费），分出去，PaymentClassification；paying的方式有多种（银行转帐，邮寄，来会计这儿取现金），分出去，PaymentMethod……每个类都是一粒珍珠，纯粹又完整，不多也不少。

 

这时候暂时忘记Pattern，忘记现实实体，心中只有两个简单的原则：Single-Responsibility Principle (SRP) 和Interface-Segregation Principle (ISP)，让他俩引导你，得到也许依赖关系不是很理想的，但是却个个都很纯粹的类结构，然后让Open-Close Principle (OCP)和Dependency-Inversion Principle (DIP)引导你重构，（当然，这时候也要注意Liskov Substitution Principle，LSP）

 

Why OCP later? 因为OCP意味着：吃下第一颗子弹先，再extracting abstraction to close against 此颗子弹，子弹就是变化，只有当变化发生了的时候你才知道需要设计什么抽象来保护自己，所以OCP 不是 BDUP (Big Design Up Front)，是事（变化）后的措施，而且是不断调整的：变化源变了，索要close的对象自然变了，原先的abstraction就要改了。

 

Then, why DIP later? 答案涉及包（package）结构的设计。首先要认识到：包结构不是系统功能划分，包结构是系统build图，因而对包结构，没有Top-Down Deisng（详见Agile Sw Dev, chapter20）。要是硬Top-Down Design就只能fail rather badly。调整包结构的核心是Acyclic-Dependencies Principle (ADP)，实现ADP的两个重要手段之一就是应用DIP，所以，先有珍珠般的、但关系不理想的类，再有大珍珠般的包。另一个手段是“Extract Package”（我这么叫它）：应该A只依赖B，但现在B也反过来依赖A了，把导致循环依赖的类单独做成一个包C，让B改为依赖C，A改为依赖B和C。

 

类设计有5个Principle（上面说了），包的设计有6个Principle：

1. The Reuse-Release Equivalence Principle (REP)
2. The Common-Reuse Principle (CRP)
3. The Common-Closure Principle (CCP)
4. The Acyclic-Dependencies Principle (ADP)
5. The Stable-Dependencies Principle (SDP)
6. The Stable-Abstraction Principle (SAP)

看着很多，其实和类的设计本质大同小异，详见Agile Sw Dev,chapter 20。值得一提的是REP谈到Reuse，我就自然联系到Component了：这一条应用于Component设计也很贴切。后来Bob大叔直接说：package应当是reuse的granularity，并且将是否适合reuse（CRP）作为package设计质量的判据之一。如此下去，package打成jar，用metadata明确说明provides-interface, requires-interface，如果需要再加点儿资源参数化（parameterize）一下，就是一个无懈可击的构件。

说到构件粒度，最让我醍醐灌顶的认识来自Oscar的文章"Software Evolution as the Key to Productivity"，他说构件之所以能提高生产率，就是因为构件提高了抽象层次，而比较之下，OO强制我们关注的概念粒度太小了。软件生产率提高的发展史就是不断提高抽象层次的历史。而"Component Software"第八章都在讨论构件粒度，第一条就是Units of abstraction。这个地方能说得太多了。

另外一个方面比较OO和Component就是：Component也许会比OO更容易学习和掌握。上面谈到OOD关于类的5条，关于包的6条principle，哪些适用于构件，哪些不适合，又要补充哪些呢？我想构件设计研究逐渐成熟后这些就会有答案，paper机会啊。因为Component不在乎impl language，（其实还是有一些要求的）所以Forrester Research调查显示为了避免OO的重新培训和较陡峭的学习曲线，许多公司正在考虑越过/抛弃OO，直奔构件，"there is a push from 'elitist objects' to 'populist components'"。但是真的会简单门吗？有个Component-Oriented Programming （COP）的东东啊，Clemens写过文章，U. of California, Irvine有个哥们拿它做了Ph.D Thesis，这下就知道不是那么简单了。管窥一下COP，Clemens给了个公式：COP = Polymorphism + (Really) Late Binding + (Real) Information Hiding + Safety （作为对照，OOP = Polymorphism + (Some) Late Binding + (Some) Information Hiding + Inheritance）

1. 第一删除的就是Implementation Inheritance
   
2. 构件是组合起来发挥作用的，所以第一要支持late binding和Polymorphism，真的late binding要求late linking——是它是真正的code integration成为现实
3. Safety不用说了，第三方开发、组合、部署的前提；老话：因为构件没有final integration test。并且构件潜在客户不可预知，所以构件系统中（不断有构件增删）无法人工判定是否可以删除构件中实例化的对象，所以真正的extensible system只能依赖垃圾收集。

COP是我一直想好好看看的东西，应该会有心得写下来。OO是实现构件的好技术，而以往的OO知识和经验在Component上绝对依然有效，但是COP设计的重点自然是向Connection侧重了，又有新的需要研究和学习。
看看OOD再结合COP，应该能悟出点儿什么，但是好像运气还未到。