设计模式的七大原则

单一职责原则（Single Responsibility Principle）

系统中的每一个对象应该只有一个单独的职责，而所有对象所关注的就是自身职责的完成

一个合理的类对外只提供一种功能，而引起类变化的原因应该只有一个

里氏替换原则（Liskov Substitution Principle）

在任何父类出现的地方都可以用它的子类代替

在同一个继承体系中的对象应该有共同的行为特征

里氏替换原则关注的是怎样良好的使用继承，也就是说不要滥用继承，它是继承复用的基石

依赖注入原则（Dependence Inversion Principle）

在应用程序中，所有类如果使用或者依赖于其他的类，则都应该依赖于这些其他类的抽象类，而不是这些其他类的具体实现类

抽象层次应该不依赖具体的实现细节，这样才能保证系统的可复用性和可维护性

依赖注入原则的本质就是通过抽象（抽象类或借口）使各个类或模块的实现彼此独立，不互相影响，实现模块间的松耦合

接口分离原则（Interface Segregation Principle）

一个接口不需要提供太多的行为，应该只提供一种对外的功能（这里的接口不仅仅是通过interface关键字定义的接口，还包括对象接口，如Phone phone = new Phone()）

接口分离原则要求在一个模块中应该只依赖它需要的接口，这就要求设计接口的时候应该尽量细化

接口分离原则与单一职责原则有些类似，不同之处在于：单一职责原则要求的是类和接口职责单一，注重的是职责，是业务逻辑上的划分；而接口分离原则要求的是接口的方法尽量少，针对一个模块尽量有用

迪米特原则（Law Of Demeter）

一个对象应该对其他对象尽可能少地了解，意思就是降低各个对象之间的耦合，提高系统的可维护性

在模块之间，应该只通过接口通信，而不理会模块的内部工作原理，它可以使各个模块耦合度降到最低，促进软件的复用

开闭原则（Open for Extension，Closed for Modification）

对象应该对扩展开放，对修改关闭

对类的改动是通过增加代码进行的，而不是改动现有的代码

也就是说，开发人员一旦写出可以运行的代码，就不应该去改变它，这就需要借助于抽象和多态来实现，即把可能变化的内容抽象出来，从而使抽象的部分是相对稳定的，而具体的实现是可以改变和扩展的