设计模式6大原则

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

定义：就一个类而言， 应该仅有一个引发它变化的缘由。

单一职责的划分界限并非那么清晰，不少时候须要靠我的经验界定。固然最大的问题就是对职责的定义，什么是类的职责，以及怎么划分类的职责。

2、开放封闭原则（Open Close Principle）

定义：类、模块、函数等应该是能够拓展的，可是不可修改。

开闭原则指导咱们，当软件须要变化时，应该尽可能经过拓展的方式来实现变化，而不是经过修改已有代码来实现。这里的“应该尽可能”4个字说明OCP原则并非说绝对不能够修改原始类的。当咱们嗅到原来的代码“腐化气味”时，应该尽早地重构，以便使代码恢复到正常的“进化”过程，而不是经过集成等方式添加新的实现，这会致使类型的膨胀以及历史遗留代码的冗余。所以，在开发过程当中须要本身结合具体状况进行考量，是经过修改旧代码仍是经过继承使得软件系统更稳定、更灵活，在保证去除“代码腐化”的同时，也保证原有模块的正确性。

3、里氏替换原则（Liskov Substitution Principle）

注：它是开闭原则的具体实现手段之一，它的核心原理是抽象

定义：全部引用基类的地方必须能透明地使用其子类的对象。

里氏替换原则的核心原理是抽象，抽象又依赖于继承这个特性，在OOP中，继承的优缺点至关明显，有点以下： （1）代码重用，减小建立类成本，每一个子类拥有父类的属性和方法； （2）子类和父类基本类似，但又与父类有所区别； （3）提升代码的可拓展性。 继承的缺点： （1）继承是侵入性的，只要继承就必须拥有弗雷的全部属性和方法； （2）可能形成子类代码的冗余、灵活性下降，由于子类必须拥有弗雷的属性和方法。 开闭原则和里氏替换原则每每是生死相依、不离不弃的，经过里氏替换来达到对扩展的开发，对修改的关闭效果。

4、依赖倒置原则（Dependence Inversion Principle）

注：关系到系统的可拓展性、拥抱变化的能力、开闭原则

定义：高层模块不该该依赖于低层模块，二者都应该依赖于抽象。抽象不该该依赖于细节，细节应该依赖于抽象。

java中抽象指接口或抽象类，二者都不能直接被实例化的；细节就是实现类，实现接口或者集成抽象类而产生的也就细节，也就是能够能够加上yige 关键字new产生的对象。高层模块就是调用端，低层模块就是具体实现类。依赖倒置原则在java中表现就是，模块间依赖经过抽象发生，实现类之间不发生直接依赖关系，其依赖关系是经过接口或者抽象类产生的。若是类与类直接依赖细节，那么久会直接耦合。如此一来当修改时，就会同时修改依赖者代码，这样限制了可拓展性。

5、 接口隔离原则（InterfaceSegregation Principles）

注：最小化， 减小依赖从而下降变动的风险。

定义：一个类对另外一个类的依赖应该创建在最小的接口上。

创建单一接口，不要创建庞大臃肿接口；尽可能细化接口，接口中方法尽可能少。也就是说，咱们要为各个类创建专用的接口，而不要试图创建一个很庞大的接口供全部依赖它的类调用。 （1）接口尽可能小，可是要有限度。对接口进行细化能够提升程序设计的灵活性；可是若是太小，则会形成接口数量过多，使设计复杂化。因此，必定要适度。 （2）为依赖接口的类定制服务，只暴露给调用的类须要的方法，它不须要的方法则隐蔽起来。只有专一得为一个模块提供定制服务，才能创建最小的依赖关系。 （3）提升内聚，减小对外交互。接口方法尽可能少用public修饰。接口是对外的承诺，承诺越少对系统开发越有利，变动风险也会越少。

以上（单一职责、开闭原则、里氏替换、接口隔离、依赖倒置）五个原则被Bob大叔在21世纪早期定义为SOLID原则。做为面向对象编程的5个基本原则，当这些原则被一块儿使用时，它们使得一个软件系统更清晰、简单，最大程度地拥抱变化。

6、 迪米特原则（Law of Demeter）也称最少知识原则

注：经过引入一个合理的第三者下降现有对象之间的耦合度。

定义：一个软件实体应当尽量少地与其余实体发生相互做用。

一个类应该对本身须要耦合或者调用的类知道最少， 类的内部如何实现与调用者或者依赖关系越密切，耦合度越大，当一个类发生变化时，对另外一个类的影响也越大。 （1）在类的划分上，应当尽可能建立松耦合的类。类之间的耦合度约低，就越有利于服用。一个处于松耦合中的类一旦被修改，则不会对关联的类形成太大的波及。 （2）在类的机构设计上， 每个类都应当尽可能下降其成员变量和成员函数的访问权限。 （3）在对其余类的引用上， 一个类对其余对象的引用应当降到最低。