记录一下，避免遗忘。
单一职责（SRP：Single Responsibility Principle）：一个类，应该仅有一个引起它变化的原因。不要将变化原因不同的职责封装在一起，而应该分离。当然，这个要求是很苛刻的，要做到仅有一个原因很难，应该是一类相似的原因。和这个原则相似的原则是迪米特法则（LoD：Law of Demeter）：又叫最少知识原则，指软件实体应该尽可能少的和其他软件实体发生相互作用。职责越少，那么引起它变化的原因也就越少、越单一。
开放封闭原则（OCP：Open Closed Principle）：软件实体应当对修改关闭，对扩展开放。避免在需求发生变化的时候，软件需要改动很多地方。在前期设计中，应该考虑到业务变动比较频繁的地方，将这些地方做适当的抽象，当业务扩展时，只需要继承和实现抽象即可，这样就不会有太多改动了。当然，不是所有地方都需要抽象，仅是变动频繁的地方，否则会造成抽象太多，代码可读性降低。
依赖倒置原则（DIP：Dependency Inversion Principle）：依赖于抽象，不要依赖于具体实现。这个道理说得很多了，听得最多的一句话就是：Programing with Interface。通过这个原则，也可以更好的实现开放封闭原则。
接口隔离原则（ISP：Interface Segregation Principle）：使用多个小的专门的接口，而不要使用一个大的总接口。实际就是避免使用“胖”接口。将不相干的功能聚合到一个接口内，那么它的实现类就要将不相干的职责封装到一个类中，大大违反了单一职责。
Liskov替换原则（LSP：Liskov Substitution Principle）：子类必须能够替换其基类。并不是说完全的替换，而是说子类和父类在行为上应当是一致的，从而保证了在实现多态的时候不会出现问题。
说到继承，这是一把双刃剑，继承能够很好的扩展系统，增加系统的灵活性，但是也容易造成系统过度庞大，代码可读性降低。所以在设计系统时应该要考虑好继承的层次深度，一般来说不要超过三层。需要深层的继承时，应该要考虑用其他方法来达到目的，比如聚合。
合成/聚合复用原则（CARP：Composite/Aggregate Reuse Principle）：在新对象中聚合已有对象，使之成为新对象的成员，从而通过操作这些对象达到复用的目的。合成方式较继承方式耦合更松散，所以应该少继承，多聚合。
