找出应用中可能变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。
针对接口编程是指针对超类型编程，变量的声明类型应该是超类型，通常是一个抽象类或者一个接口， 因此只要具体实现此超类型的类所产生的对象都可以指定给这个变量。声明时不用理会以后执行时的真正对象类型。
示例：
Dog d = new Dog();
d.bark();Animal animal = new Dog();
animal.makeSound();
使用组合建立的系统具有很大的弹性，不仅可以将算法族封装成类，更可以“在运行时动态地改变行为”， 只要组合的行为对象符合正确的接口标准即可。
两者是松耦合的，只要他们之间的接口仍被遵守，就可以自由地改变他们。
松耦合可以建立弹性的 OO 系统，能够应对变化，因为对象之间的相互依赖降到了最低。
我们的目标是允许类容易扩展，在不修改现有代码的情况下，就可搭配新的行为
当你直接实例化一个对象时，就是在依赖它的具体类。 不能让高层组件依赖低层组件，而且，不管高层或低层组件，两者都应该依赖于抽象。 所谓高层组件是指由其他底层组件定义起行为的类。
对于高层和低层组件都应该依赖抽象类而不依赖具体类。
避免违反依赖倒置原则：
- 变量不可以持有具体类的引用。如果使用 new 就会持有具体类的引用
- 不要让类派生自具体类。如果派生自具体类，就会依赖具体类。请派生自一个抽象（接口或抽象类）
- 不要覆盖基类中已实现的方法。如果覆盖基类中已实现的方法，那么你的基类就不是一个真正适合被继承的抽象。 基类中已实现的方法，应该由所有的子类共享。
最少知识原则：只和你的密友谈话。
最小只是原则告诉我们要减少对象之间的交互，只留下几个“密友”。
在设计一个系统时，不管是任何对象，都要注意它所交互的类有哪些，并且注意它和这些类是如何交互的。
在设计中，不要让太多的类耦合在一起，免得修改系统中的一部分，会影响到其他部分。如果许多类之间相互依赖， 那么这个系统会变成一个易碎的系统，需要花许多成本维护，也会因为太复杂而不容易被其他人了解。
就任何对象而言，在该对象的方法内，我们应该只调用属于以下范围的方法（调用界限）：
- 该对象本身
- 被当做方法的参数而传递进来的对象
- 此方法所创建或实例化的任何对象
- 对象的任何组件
如果某对象是调用其他方法的返回结果，不要调用该对象。
把组件想象成是被实例变量所引用的任何对象，换句话说是把这想象成是“有一个”（HAS-A）关系。
将方法调用保持在界限内。 可以减少对象之间的依赖，减少软件维护成本
- 会导致更多的“包装”类被制造出来，以处理和其他组件的沟通
- 会导致复杂度和开发时间的增加，降低运行时性能
好莱坞原则：别调用（打电话给）我们，我们会调用（打电话给）你。
允许低层组件将自己挂钩到系统上，但是高层组件会决定什么时候和怎样使用这些低层组件。高层组件 对待低层组件的方式是“别调用我们，我们会调用你”
当我们设计模板方法时，我们告诉子类：不要调用我们，我们会调用你。
避免让高层组件和低层组件之间有明显的环状依赖。
类的每个责任都有改变的潜在区域。超过一个责任，意味着超过一个改变的区域。
尽量让每个类保持单一责任。
避免类内的改变，因为修改代码容易造成许多潜在的错误。
高内聚，低耦合。