面对对象的六大原则

1. 单一职责原则(Single Responsibility Principle)

• 就一个类而言，应该仅有一个引起它变化的原因。
• 两个完全不一样的功能就不应该放在一个类中。
• 一个类中应该是一组相关性很高的函数、数据的封装。

2. 开闭原则(Open Close Principle)

• 软件中的对象(类、模块、函数等)应该对于拓展是开放的，对于修改是封闭的。
• 尽量通过扩展的方式来对实现原有代码的变化、升级和维护，而不是通过修改已有的代码来实现。
• 程序一旦开发完成，程序中一个类的实现只因错误而被修改，新的或者改变的特性应该通过新建不同的类实现，新建的类可以通过继承的方式来重用原类的代码。
• 代码本身写的结构不好，就应该尽早地重构，以便是代码恢复到正常的“进化”，而不是通过继承等方式来添加新的实现，这会导致类型的膨胀以及历史遗留代码的冗余。

3. 里氏替换原则(Liskov Subsititution Principle)

• 任何基类可以出现的地方，子类一定可以出现。
• 里氏替换原则核心是 抽象 ，依赖于 继承、多态 两大特性。
• 建立抽象，通过抽象建立规范。具体的实现在运行时替换掉抽象，保证系统的扩展性、灵活性。
• 抽象是走向代码优化的第一步。

4. 依赖倒置原则(Dependence Inversion Principle)

• 高层模块不应该依赖底层模块，两者都应该依赖其抽象。
• 抽象不应该依赖细节。
• 细节应该依赖抽象。
• 模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象产生的。

5. 接口隔离原则(InterfaceSegregation Principles)

• 客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。

6. 迪米特原则(Law Of Demeter)

• 一个类应该对自己需要耦合或调用的类知道得最少，类的内部如何实现与调用者或者依赖者没关系，调用者或者依赖者只需要知道它需要的方法即可，其他的一概不管。

总结

• 抽象、单一职责、最小化。
• 在应用开发过程中，最难的不是完成应用的开发工作，而是在后续的升级、维护过程中让应用系统能够拥抱变化.