【设计模式】六大原则

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

对一个类而言，应该仅有一个引起它变化的原因。如果存在多于一个动机去改变一个类，那么这个类就具有多于一个的职责，就应该把多余的职责分离出去，再去创建一些类来完成每一个职责。单一职责原则是实现高内聚低耦合的最好方法，没有之一。

2.里氏替换原则(Liskov's Substitution Principle)：

子类可以扩展父类的功能，但是不能改变父类原有的功能。

继承必须明确确保超类（父类）所拥有的性质在子类中仍然成立。

所有用父类的地方都可以用子类替换，子类不会override修改父类的方法，只会扩展

3.依赖倒置原则(Dependency Inversion Principle)：

设计程序时，要依赖抽象类、接口，而不是具体的实现类，高层模块不应该依赖底层模块，二者都应该依赖其抽象和接口；抽象不依赖细节；细节应该依赖抽象，面向接口编程。

4.接口隔离原则(Interface Segregation Principle)：

客户端不应该依赖它不需要的接口，类间的依赖关系应该建立在最小的接口上，接口尽量细化，同时保证接口中的方法尽量的少。

回到上述的单一职责原则，要求行为分离接口接口细化，感觉有些相同。单一职责原则要求类与接口的职责单一，注重的是职责，没有要求接口尽量的少。

在接口隔离原则中，要求尽量使用多个专门的接口。专门的接口也就是提供给多个模块的接口。提供给几个模块就应该有几个接口，而不是建立一个臃肿庞大的接口，所有的模块都可以访问。

但是接口的设计是有限度的。接口的设计粒度越小系统越灵活，这是事实，但是接口太多这也就使得结构复杂，维护难度大。因此实际中，怎样把握就靠开发的经验和常识了。

5.开闭原则(Open Close Principle)：

对扩展开放，对修改关闭。

已经完成并测试过的代码，应该尽量少的去改动它 ，以免引起新的问题。我们可以创建抽象类来隔离之后发生的变化。

6.迪米特法则（Law of Demeter）又叫最少知识原则（Least Knowledge Principle）:

一个对象应当对其他对象有尽可能少的了解,不和陌生人说话。

迪米特法则不希望类之间建立直接的联系。如果真的有需要建立联系，也希望能通过它的友元类来转达。因此，应用迪米特法则有可能造成的一个后果就是：系统中存在大量的中介类，这些类之所以存在完全是为了传递类之间的相互调用关系——这在一定程度上增加了系统的复杂度。