翻译 | 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

 

本篇归纳性的介绍了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 稳定抽象原则 抽象性随稳定性而增长。

---

更多内容敬请关注 vivo 互联网技术微信公众号

注：转载文章请先与微信号：labs2020 联系。