软件业曾经爆发过的所有变革里，其中曾经有两个派系如此广泛的深入人心，它们就是结构化编程和面向对象编程。所有主流的现代编程语言都被它们两个激烈的影响着。实际上，要想不像结构化和面向对象编程的样子来编写程序都是一件难事。我们的主流编程语言都没有goto，因此它们服从了结构化编程中最重要的禁令。我们的大多数主流编程语言都是基于类的，而且不支持在类以外定义函数或是变量，因此也避免了面向对象编程中最容易坠入的陷阱。
用这些编程语言所编写的程序可能看起来是结构化的或是面向对象的，可是“看起来”是会欺骗人的。当今的编程语言经常不顾他们所从属那种派系的编程语言的基本原则。我会在另篇blog中再探讨结构化编程的原则，本篇，我想要谈论的是面向对象编程的基本原则。
在1995年的三月，我写了一篇文章并发表在comp.object上，那是我第一次写OOD（译注1）原则的文章，此后就一发不可收拾的写了很多。你可以在我的PPP一书（译注2）中看到它们，在object mentor的很多文章中也都有，其中就有那篇众所周知的纲要（近期会译为中文，请关注）。
这些原则着重于OOD中的依赖管理方面，而淡化抽象与建模方面。这并不是说OO在抽象方面不够强大，或是OO不适合构建模型。当然有很多人都在使用OO的这些部分，只是这些原则集中关注于依赖管理。
依赖管理是我们每个人都要面对的问题，每当我们在屏幕面前打开那些彼此纠结又令人作呕的代码，我们就会遭受不良的依赖管理所带来的恶果。不良的依赖管理导致代码难以改变，易被破坏，而且不可重用。实际上，我在PPP一书中谈论过很多不同的设计坏味道，而这些都与依赖管理有关。从另一方面来说，如果依赖经过了良性的管理，代码就可以保持灵活性、健壮性和重用性。所以依赖管理和这些相关原则是程序员们渴求的让软件保持优良架构的基石。
头五项原则是关于类设计的，它们是：
◆ SRP，单一职责原则，一个类应该有且只有一个改变的理由。
◆ OCP，开放封闭原则，你应该能够不用修改原有类就能扩展一个类的行为。
◆ LSP，Liskov替换原则，派生类要与其基类自相容。
◆ DIP，依赖倒置原则，依赖于抽象而不是实现。
◆ ISP，接口隔离原则，客户只要关注它们所需的接口。
另外的六项是关于包的设计原则。在本文中，包是指一个二进制的可发布文件，比如.jar文件、或dll文件，而不是Java包或是C++的命名空间（译注3）。
头三项包原则是关于包内聚性的，它们会告诉我们该把什么划分到包中：
◆ REP，重用发布等价原则，重用的粒度就是发布的粒度。
◆ CCP，共同封闭原则，包中的所有类对于同一类性质的变化应该是共同封闭的。
◆ CRP，共同重用原则，一个包中的所有类应该是共同重用的。
最后的三项原则是关于包之间的耦合性原则的，并且论述了评价系统中包结构优良与否的评判标准。
◆ ADP，无环依赖原则，在包的依赖关系图中不允许存在环。
◆ SDP，稳定依赖原则，朝着稳定的方向进行依赖。
◆ SAP，稳定抽象原则，包的抽象程度应该和其稳定程度一致。
译注：
1，OOD，全称Object Oriented Design，即面向对象设计。
2，PPP，即Bob大叔的著作《敏捷软件开发 原则、模式与实践》一书以及其相关书籍，因都有“原则、模式与实践”，即Priciples, Patterns and Practices，故常简称为PPP。
3，命名空间，原文为namespace，也译作名字空间。它是一种特殊的作用域，它包含了处于该作用域内的所有标示符，且本身也用一个标示符来表示，这样便于将一系列在逻辑上相关的标示符用一个标示符来组织。就Java编程语言来说，命名空间是通过java包来表达的，所有代码都归属与一个包。来自其他包中的代码要通过指定包名来引用某项特定的标示符，例如，包java.lang中的String类要通过java.lang.String的形式引用。在C++中，命名空间常用来避免命名冲突，尽管现今的C++语言对命名空间做出了扩展，但过去的C++代码很少使用此项功能。
