里氏替换原则(LSP)
定义：子类型必须能够替换掉它们的基类型。
- 一个自相容的设计未必就和所有的用户程序相容。
- 一个模型，如果孤立地看，并不具有真正意义上的有效性。模型的有效性只能通过它的客户程序来表现。
正是子类型的可替换性才使得使用基类类型的模块在无需修改的情况下就可以扩展。这种可替换性必须是开发人员可以隐式依赖的东西。
依赖导倒置原则(DIP)
- 高层模块不应该依赖于低层模块。二者都应该依赖于抽象。
- 抽象不应该依赖于细节。细节应该依赖于抽象。
本应该是高层的策略设置模块去影响低层的细节实现模块的。包含高层业务规则的模块应该优先并独立于包含实现细节的模块。 无论如何高层模块都不应该依赖于低层模块。
此外,我们更希望能够重用的是高层的策略设置模块。我们已经非常擅长于通过于程序库的形式来重用低层模块。如果高层模块依赖于低层模块，那么在不同的上下文中重用高层模块就会变得非常困难。
然而，如果高层模块独立于低层模块，那么高层模块就可以非常容易地被重用。 该原则是框架设计的核心原则。使用传统的过程化程序设计所创建出来的依赖关系结构，策略是依赖于细节的。这是糟糕的，因为这样会使策略受到细节改变的影响。面向对象的程序设计倒置了依赖关系结构，使得细节和策略都依赖于抽象，并且常常是客户拥有服务接口。
事实上，这种依赖关系的倒置正是好的面向对象设计的标志所在。使用何种语言来编写程序是无关紧要的。如果程序的依赖关系是倒置的，它就是面向对象的设计。如果程序的依赖关系不是倒置的，它就是过程化的设计。
依赖倒置原则是实现许多面向对象技术所宣称的好处的基本低层机制。它的正确应用对于创建可重用的框架来说是必须的。同时它对于构建在变化面前富有弹性的代码也是非常重要的。由于抽象和细节被彼此隔离，所以代码也非常容易维护。
接口隔离原则(ISP)
- 不应该强迫客户依赖于它们不用的方法。
胖类会导致它们的客户程序之间产生不正常的并且有害的辑合关系。当个客户程序要求该胖类进行一个改动时，会影响到所有其他的客户程序。
因此，客户程序应该仅仅依赖于它们实际调用的方法。通过把胖类的接口分解为多个特定于客户程序的接口，可以实现这个目标。每个特定于客户程序的接口仅仅声明它的特定客户或者客户组调用的那些函数。
接着，该胖类就可以继承所有特定于客户程序的接口，并实现这就解除了客户程序和它们没有调用的方法间的依赖关系，并使客户程序之间互不依赖。