设计模式已经是针对 某个场景下 某些问题的 某个解决方案。
也就是说这些设计原则是思想上的指导，而设计模式是实现上的手段，因此设计模式也应该遵守这些原则.
换句话说，设计模式就是这些设计原则的一些具体体现。
一个类应该仅有一个引起它变化的原因。
一个类应该对扩展开放，对修改关闭。 开闭原则要求的是，类的行为是可以扩展的，而且是在不修改已有代码的情况下进行扩展。
子类型必须能够替换掉它们的父类型。
这很明显是一种多态的使用情况，它可以避免在多态的应用中，出现某些隐蔽的错误。
事实上，当一个类继承了另外一个类，那么子类就拥有了父类中可以继承下来的属性和操作。
理论上来说，此时使用子类型去替换掉父类型，应该不会引起原来使用父类型的程序出现错误。
但是，很不幸的是，在某些情况下是会出现问题的。
比如，如果子类型覆盖了父类型的某些方法，或者是子类型修改了父类型某些属性的值，那么原来使用父类型的程序就可能会出现错误，因为在运行期间，从表面上看，它调用的是父类型的方法，需要的是父类型方法实现的功能，但是实际运行调用的却是子类型覆盖实现的方法，而该方法和父类型的方法并不一样，于是导致错误的产生。
从另外一个角度来说，里氏替换原则是实现开闭的主要原则之一。
开闭原则要求对扩展开放，扩展的一个实现手段就是使用继承；
而里氏替换原则是保证子类型能够正确替换父类型，只有能正确替换，才能实现扩展，否则扩展了也会出现错误。
要依赖于抽象，不要依赖于具体类。要做到依赖倒置，典型的应该做到：TODO 面向接口编程?
高层模块不应该依赖于底层模块，二者都应该依赖于抽象。 抽象不应该依赖于具体实现，具体实现应该依赖于抽象。 所谓接口隔离原则，指的是，不应该强迫客户依赖于他们不用的方法。
因此，这样的接口应该被分离，应该按照不同的客户需要来分离成为针对客户的接口。
这样的接口中，只包含客户需要的操作声明，这样既方便了客户的使用，也可以避免因误用接口而导致的错误。
分离接口的方式，除了直接进行代码分离之外，还可以使用委托来分离接口，在能够支持多重继承的语言中，还可以采用多重继承的方式进行分离。
所谓最少知识原则，指的是，只和你的朋友谈话。
这个原则用来指导我们在设计系统的时候，应该尽量减少对象之间的交互，对象只和自己的朋友谈话，也就是只和自己的朋友交互，从而松散类之间的耦合。
那么究竟哪些对象才能被当作朋友呢？最少知识原则提供了一些指导。 ■ 当前对象本身。 ■ 通过方法的参数传递进来的对象。 ■ 当前对象所创建的对象。 ■ 当前对象的实例变量所引用的对象。 ■ 方法内所创建或实例化的对象。
除了上面提到的这些原则，还有一些大家都熟知的原则，比如： ■ 面向接口编程； ■ 优先使用组合，而非继承。 ■ 一个类需要的数据应该隐藏在类的内部； ■ 类之间应该零耦合，或者只有传导耦合，换句话说，类之间要么没有关系，要么只使用另一个类的接口提供的操作； ■ 在水平方向上尽可能统一地分布系统功能；
