设计模式的六大原则

原则一：单一职责原则

定义：英文名称是Simple Responsibility Principle, 简称SRP，一个类应该仅有一个引起它变化的原因，换句话说就是一个类只负责一项职责。

在软件开发过程中，一个类职责越多，它被复用的可能性就会越小，将多个职责写在一个类中，这些职责就不可避免的产生耦合，当一个职责改变时，很可能会影响其他职责的正常运行，这违反了软件开发中高内聚，低耦合的重要原则，既影响软件的质量，又给我软件的维护带来了很大的麻烦。因此将多个职责进行分离，根据不同的职责封装成不同的类是很重要的。

单一职责原则说起来容易，但实际开发中做起来确实是比较难的，因为我们往往很难去划分清楚一个类的职责。

原则二：开闭原则

英文名称是Open Close Priciple， 简称OCP，

软件中的实体(类，模块，方法等)应该对扩展是开放的，对修改是关闭的。即软件实体应尽量在不修改原有代码的情况下进行扩展。

在软件的开发和维护的过程中，在对原有代码的修改时，很可能会将错误带入到原来已经测试通过的旧代码中，破坏了原有的代码，因此当软件需要变化是，我们应该尽量不改变原有代码，应该尽量通过扩展的方式来实现变化，这里之所以说”尽量”是因为在实际开发中我们很难做到只通过扩展来升级和维护软件，绝大多数情况下修改和扩展都是同时存在的，但我们还是要尽量少去修改原有代码。

原则三：里氏替换原则

所有引用基类的地方必须能使用其子类的对象，只要父类出现的地方子类就可以出现，并且将父类替换子类不会产生错误和异常，换句话说就是子类的功能必须大于或者等于父类，即父类可以使用的方法，子类都可以使用。

面向对象有三大特性：继承，封装，多态；里氏替换原则就是依赖继承和多态。从里氏替换原则的定义可以得出一个很重要的编程的规范，简单来说就是子类继承父类时应该尽量避免覆盖父类的方法，子类应该扩展父类的功能，但不应该覆盖父类的功能。

原则四：依赖倒置原则

Dependence Inversion Principle , 依赖倒置原则就是应该依赖于抽象，不应该依赖于具体， 换句话说就是高层次的模块不依赖于低层次模块的实现细节，依赖模块被颠倒了。

抽象：在java中抽象指抽象类，接口；这两者都是不能被实例化的，只能通过其他类去实现它。

细节：细节其实就是指抽象类和接口的实现类，它是可以被实例化的。

依赖倒置原则注意以下三点：

（1）高层次模块不应该依赖低层次模块，两者都应该依赖其抽象；

（2）抽象不应该依赖细节；

（3）细节应该依赖于抽象；

在面向对象开发中，大多数情况下抽象的变化的可能性要比实现细节变化的可能性小的多，因此开发过程中尽量使实现的细节依赖于抽象，即使实现细节不断变化，只要抽象不变，用户端程序就不需要变化太大。

其实依赖倒置原则就是平时常见的面向接口编程

原则五：接口隔离原则

客户端程序不应该依赖它不需要的接口，换句话说就是接口的建立应该尽可能的细化，不应该建立功能五花八门的接口，接口中的方法尽量少。应该为每个类建立自己专用的接口，而不应该去建立一个很庞大的接口供所有依赖它的类去调用，类之间的依赖关系应该建立在最小的接口上，接口隔离原则的目的是对系统解耦，使程序更容易重构和维护。

原则六：迪米特法则

Law of Demeter, 迪米特法则也称最少知识原则

一个对象应该对其他对象有最少的了解。通俗地讲，一个类应该对自己需要耦合或调用的类知道得最少，类的内部如何实现与调用者应该没有关系，调用者只需要知道它需要调用的方法即可。我们在写一个类时不应该将类中的具体实现细节暴露出来，应该只需要对外暴露对其外部对其调用的方法(public方法)即可。

一个类public属性，方法越多，外部对该类调用的途径也就越多，如果在维护的过程中需要修改该类，那么需要修改的面也就越广，产生错误的风险也就越大，维护的成本也就越高。因此，迪米特法则要求我们在写一个类时应该正确的使用访问控制符(public， private，protected等)。

如有错误，欢迎指正，谢谢！