翻译 | The Principles of OOD 面向对象设计原则
本文首发于vivo互联网技术微信公众号 https://mp.weixin.qq.com/s/Q_pziBUhKRywafKeY2T7YQ
作者：Robert C. Martin
翻译：张硕
本文由来自美国业界大牛——Robert C. Martin（俗称“Bob大叔） 发布在 butunclebob.com 上，已获得翻译授权。
英文原文链接：[http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod]（http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod）
本篇概括性的介绍了OOD的设计原则，后续还有更多文章会详细剖析、吃透面向对象业务设计的原则。
什么是面向对象设计？它是怎么一回事？使用它会有什么利弊得失？似乎问出这些问题显得有些愚蠢，特别是在一个几乎每个开发者都会使用某种面向对象语言的时代中。
然而在我看来，这些问题即极为重要，因为我们中的大多数使用者并不知道答案，当然也不知道如何发挥面向对象语言的最大价值。
在我们这个行业发生的所有变革中，有两场是非常成功的，以至于它们已经渗透到我们的思维中，以至于我们认为它们是理所当然的。那就是"结构化设计编程"(也叫面向过程设计)与"面向对象设计编程"。所有主流的现代编程语言都被这两种编程范式深刻影响。甚至是，我们很难摒弃这两种编程范式去写任何一个程序。
我们的主流编程语言中没有“GOTO”，因此似乎是遵守了著名的结构化编程"禁令"；我们大多数的主流编程语言是基于类并且不支持使用没有写入任何一个类中的变量、函数(方法)，因此他们似乎是遵守了面向对象设计中最明显的特点。
用这些语言(主流结构化语言或面向对象语言)写出的程序也许看上去是结构化的或面向对象的，但是外表也可以是虚假的。今天的程序员常常不知道这些语言产生的原因以及其中的基础原则。在另一篇博客中，我会讨论结构化编程的设计原则，而在这篇文章中我想要聊聊面向对象设计原则。
在1995年3月，在comp.object上，我写过一篇文章，这篇文章也成为我日后众多OOD设计原则文章中的处女作。你们将会在我的PPP书籍中以及发表了我多篇文章的objectmentor网站上看到这些文章，当然也包括那个广为人知的那篇摘要文章。（译者注：PPP指——“Agile Software Development: Principles, Patterns, and Practice,中文即—敏捷软件开发：原则、模式与实践”）
这些原则揭示了OOD依赖管理方面的内涵，而在概念化和建模方面并没有深入涉及。然而这并不代表OO在对问题领域的概念化上很薄弱，也不代表OO在建模能力上很薄弱。我很确定在这两方面上，很多从OO设计原则中获得价值。需要注意的是，这些原则非常关注依赖关系管理。
（译者注：此处指宽泛概念的依赖关系管理，如系统与系统之间的依赖，模块与模块之间的依赖，类方法直接的依赖）
依赖管理是一个大多数架构师需要面对的问题。每当我们在屏幕上看到一堆乱七八糟的遗留代码时，我们都在经历依赖管理不善的结果。糟糕的依赖关系管理导致代码难以更改、脆弱和不可重用。实际上，在我的PPP书中谈到了几种不同的设计风格，都与依赖管理有关。另一方面，当依赖关系得到很好的管理时，代码仍然是灵活可扩展的、健壮的和可重用的。因此，依赖关系管理的思考，以及这些原则的使用，是软件开发人员设计灵活性系统的基础。
以下5个原则是阶级设计原则：
- SRP单一职责原则 指一个类模块包甚至系统 都应该有单一的原则。
- OCP开闭原则 你应该能够扩展类的行为，而不需要修改它。
如果软件系统想要更容易被改变，其设计就必须允许新增代码来修改，而非修改原来代码。
- LSP 里氏替换原则
简答理解就是 如果想要可替换的组件来构建软件系统，那么这些组件就必须遵守共同一个约定，以便让这些组件可以相互替换。
- ISP 接口隔离原则
使细粒度接口特定于客户端,主要告诫设计师应该在设计中避免不必要的依赖。
- DIP 依赖倒置原则
依赖抽象，而非具体实现。此原则指出高层策略性代码不应该依赖实现的代码，相反，那些底层实现应该依赖于高层策略代码。（译者注：这里的“类”泛指：方法和数据的耦合分组）
接下来的六条原则是关于包（译者注：指jar、war，而非package）的。在这个上下文中，包是二进制的可交付文件，比如：jar文件，或者dll，而不是java包或c++命名空间。前三个包原则是关于包内聚的，它们告诉我们在包中放入什么：
- REP 重用发布等价原则 重用的颗粒就是释放的颗粒。
- CCP 共同封闭原则 一起更改的类被打包在一起。
- CRP 共同重用原则 一起使用的类被打包在一起。
- ADP 无环依赖原则 包的依赖关系图必须没有循环。
- SDP 稳定依赖原则 依赖于稳定性的方向，特别是（变化更多的）具体的元素应该取决于是否要完全依赖于（更稳定的）抽象成分。
- SAP 稳定抽象原则 抽象性随稳定性而增加。