识别出应用里改变的方面，然后把它们从不变部分里分离出来封装。这样变化的部分就不会影响到不变的部分。那么，之后代码改变的话，只需要修改封装好的变化部分，不引起无意的修改，并提供更好的扩展灵活性。

1. 由接口定义要实现的每个行为；
2. 只要依照接口定义好的编程实现；
3. 我们只需要知道接口是如何，根本不需要实现的细节而去使用这个接口派生的对象；
4. 在运行时才赋值具体的实现对象。

使用组合创建系统提高灵活性。不单单可以使你把一族的算法封装成它们各自的类，同时让你在运行时可以改变算法行为。

而继承，子类直接实现好算法的具体行为，不能在运行时改变算法的行为，同时过多的继承加剧类图的复杂度。

当两个对象松耦合时，它们能交互，但互相了解很少。松耦合让我们建立能适应变化的灵活系统，因为它们最小化对象间的内部依赖。

松耦合对象 A 和 B：

1. A 和 B 只要知道对方的接口，就可以互相调用对方;
2. 我们可以独立复用 A 或 B;
3. 改变 A 或 B 不会影响对方。

1. 开放：自由添加任何新的行为来扩展类。
2. 闭合：现有的代码经过长时间的测试和修正，不允许别人修改现有代码。

目的是允许类能容易的被扩展新的行为而不用修改现有的代码。为了达到这个目的，模式设计需要能弹性改变并足够灵活来对变化需求的新功能做出反应。

与“面向接口编程，而不是实现“原则类似，然而依赖反转原则对于抽象接口更严格：

1. 高层次的模块不应该依赖于低层次的模块，两者都应该依赖于抽象接口。
2. 抽象接口不应该依赖于具体实现。而具体实现则应该依赖于抽象接口。

得墨忒耳定律是松耦合的一种具体案例:

1. 每个单元对于其他的单元只能拥有有限的知识：只是与当前单元紧密联系的单元；
2. 每个单元只能和它的朋友交谈：不能和陌生单元交谈；
3. 只和自己直接的朋友交谈

这个原理的名称来源于希腊神话中的农业女神，孤独的得墨忒耳。

总的概括就是：不要调用我们（高层次模块），我们会调用你（低层次模块）。

好莱坞原则提供一种防止依赖腐烂的方法。依赖腐烂发生当高层次模块依赖于低层次模块，低层次模块依赖于高层次模块，高层次模块又依赖于边际模块，边际模块依赖于低层次模块如此。当腐烂发生，没有人能轻易理解这个系统如何设计。

遵循好莱坞原则，允许低层次模块连入到系统中，但是由高层次模块决定什么时候它们被需要，和怎么使用它们。而不允许低层次的模块直接去调用一个高层次模块。

单一功能原则（Single responsibility principle）规定每个类都应该有一个单一的功能，并且该功能应该由这个类完全封装起来。

也就是一个类或者模块应该有且只有一个改变的原因。一个具体的例子就是，想象有一个用于编辑和打印报表的模块。这样的一个模块存在两个改变的原因。第一，报表的内容可以改变（编辑）。第二，报表的格式可以改变（打印）。这两方面会的改变因为完全不同的起因而发生：一个是本质的修改，一个是表面的修改。单一功能原则认为这两方面的问题事实上是两个分离的功能，因此他们应该分离在不同的类或者模块里。把有不同的改变原因的事物耦合在一起的设计是糟糕的。

保持一个类专注于单一功能点上的一个重要的原因是，它会使得类更加的健壮。继续上面的例子，如果有一个对于报表编辑流程的修改，那么将存在极大的危险性，打印功能的代码会因此不工作，假使这两个功能存在于同一个类中的话。