本节书摘来自异步社区《面向对象设计实践指南：Ruby语言描述》一书中的第1章，第1.2节设计工具，作者【美】Sandi Metz，更多章节内容可以访问云栖社区“异步社区”公众号查看。
1.2 设计工具
面向对象设计实践指南：Ruby语言描述
设计可不是遵循一套固定规则就完事的动作。它是每次沿着一条分支前进的旅行，在这条路径上早期的选择关闭了某些选择，同时又会打开其他新的选择。在设计过程中，你会徘徊于各种错综复杂的需求中，这里的每个关键时刻都代表着一个决策点，它会对将来产生影响。
像雕塑家有凿子和文稿一样，面向对象的设计师也有自己的工具—原则和模式。
1.2.1 设计原则
SOLID原则首先由Michael Feathers提出，再由Robert Martin进行了推广。它代表了5个最有名的面向对象设计原则，即单一职责原则（Single Responsibility Principle，SRB）、开闭原则（Open-Closed Principle，OCP）、里氏替换原则（Liskov Substitution Principle，LSP）、接口隔离原则（Interface Segregation Principle，ISP）以及依赖倒置原则（Dependency Inversion Principle，DIP）。另外还有其他一些原则，如Andy Hunt和Dave Thomas提出的不重复原则（Don’t Repeat Yourself，DRY），以及源于美国东北大学迪米特项目的迪米特法则（Law of Demeter，LoD）。
这些原则都贯穿于全书。现在的问题是：“它们究竟从何而来？”这些原则很有价值，有证据证明吗？或者它们只是某些人的个人观点，你甚至可以对其随意贬损，情况是如此吗？归根结底，它们究竟是谁提出来的？
所有这些原则在一开始都只是人们在编写代码时所做的一些选择。早期的面向对象程序员发现有些代码编排可以让他们的工作变得更轻松，而其他的编排则会让他们感觉更累。这些经验引导他们形成了如何编写出优秀代码的观点。
后来，学者们参与了进来。为撰写研究论文，他们于是决定要量化“什么是优秀代码”。这种想法很值得称赞。如果能对事物进行统计（如计算代码的度量指标），并将这些度量指标与应用程序质量的高低关联起来（为此，我们还需要一个客观的测量标准），那么我们就可以多做能降低成本的事情，少做会增加成本的事情。能够对质量进行测量将OO设计从争论不休的观点变成为可测量的科学。
20世纪90年代，Chidamber、Kemerer1和Basili2正好从事这方面的研究。他们收集了许多面向对象的应用程序，想尽一切办法改善这些编码的质量。他们为很多事情进行命名和测量，如类的整体尺寸、多个类之间彼此的关联度、继承层次的深度和广度，以及以任何发送消息的结果形式获得调用的方法的数量。他们选择了自己认为很重要的代码进行编排，并设计出公式来对它们进行统计，然后将最终的度量与封闭程序的量进行关联。他们的研究显示：这些技术的使用和高质量的代码之间存在显著关联。
虽然这些研究看起来是证明了设计原则的有效性，但对于任何经验丰富的程序员来说，都需要慎重选用它们。早期的研究都只是检查了由一些研究生编写的非常小型的应用程序，仅此一点就足以证明需要审慎地看待这些结论。这些应用程序里的代码不可能完全代表真实世界里的OO应用程序。
不过，事实证明这种谨慎是多余的。2001年，Laing和Coleman检查了多个NASA Goddard太空飞行中心的应用程序（火箭科学），并希望能找到“一种能生产出更便宜和高质量软件的方法” 3。他们检查了三个优劣各异的应用程序，其中一个包含1 617个类和500 000多行代码。他们的研究完全支持先前的研究成果，从而进一步证实了设计原则的重要性。
即使是你从未阅读过这些研究，也可以对他们的结论持有信心。那些实现优秀设计的原则所代表的是可测量的真理，遵循它们能改善你的代码。
1.2.2 设计模式
除了这些原则，面向对象设计还包含了许多模式。有一个所谓的“四人组”（Gang of Four， Gof），即Erich Gamma、Richard Helm、Ralph Johnson和Jon Vlissides，他们于1995年一起编写了关于模式的开创性著作。他们的书籍《设计模式》将模式描述为“在面向对象的软件设计中，针对特定问题的简单而优雅的解决方案”，你可以用它来“让自己的设计更加灵活、更具有模块化、更易重用和更易理解”。4
设计模式的概念极其强大。对常见问题进行命名，并使用常用的方法来解决这些问题，采用这种方式可以将模糊的内容聚焦在一起。设计模式为整整一代的程序员提供了交流和协作的手段。
在每位设计师的工具箱里总能见到多种模式的存在。对其所解决的问题来说，每一个无人不晓的模式都是一种近乎完美的开源解决方案。不过，模式的流行也导致有的模式被程序员新手过度滥用的问题。他们有时会热情过头，将非常优秀的模式应用到错误的问题上。模式的误用会导致代码变得非常复杂且混乱不堪，但是出现这样的结果并不是模式本身的问题。一种工具不能因其用途而受到责怪，使用者必须要掌握好这个工具。
本书不是要讨论模式，而是会想方设法让你理解它们，并且教你如何正确地选择和使用它们。
**1 Chidamber, S. R., & Kemerer, C. F. (1994). A metrics suite for object-oriented design. IEEE Trans. Softw. Eng. 20(6): 476–493.
2 Basili Technical Report (1995). Univ. of Maryland, Dep. of Computer Science, College Park, MD, 20742 USA. April 1995. A Validation of Object-Oriented Design Metrics as Quality Indicators.
3 Laing, Victor & Coleman, Charles. (2001). Principal Components of Orthogonal Object-Oriented Metrics (323-08-14).
4 Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1995). Design Patterns, Elements of Reusable Object-Oriented Software. New York, NY: Addison-Wesley Publishing Company, Inc.**
本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。
