设计模式六大原则、你还记得多少？

一、写在前面

提及设计模式我想对每个猿友来讲都是一个油腻的话题、23中设计模式张口就来。然而对于这些模式的的设计原则你们还能记起多少？了解多少以及用到多少尼？下面就让咱们来一块儿回顾下。

二、六大设计原则

设计模式六大设计原则分别为、开-闭原则、里氏代换原则、依赖倒转原则、合成/聚合复用原则、迪米特法则、接口隔离原则等六大设计原则。

下面让咱们一一介绍下他们吧！

2.一、“开-闭”原则 (ocp)

经典力学的基石是牛顿三大定义、而面向对象可复用设计的第一块基石，即是所谓的“开-闭”原则（open-closed-principle）.

什么是“开-闭”原则？？？？？？

“开-闭”原则讲的是：一个软件实体应当对扩展开放、对修改关闭（膜拜下 Bertrand Meyer）。

就是说：设计一个模块时、应当使这个模块在不被修改的前提下被扩展。

程序猿语言：应当能够在没必要修改源码的状况下改变这个模块的行为。

全部的软件系统有个一共同的特性、即对他的需求会随着时间的推移而改变（固然这不是程序猿大战产品的理由）。
在软件系统面临新的需求时，系统必须是稳如磐石的。

知足“开-闭”原则的设计能够给一个软件系统提供两个无可比拟的优点（少干架）

1: 经过扩展已有软件系统，能够提供新的行为、以知足对软件系统的新需求，使变化中的系统有必定的适应性和灵活性

2: 已有的软件模块、特别是抽象层的模块是万万不能在修改的，这就使变化中的软件系统有必定的稳定性和延续性。

具备这两个优势的软件系统、是一个高层次上实现了复用的系统、也是一个易于维护和扩展的系统。

如何实现“开-闭”原则？？？

咋看起来、不能修改和能够扩展是相互矛盾的。怎么来实现不能修改的同时用能扩展尼？？？

解决问题关键仍是老生常谈的抽象化了。咱们都知道Java语言是一个面向对象的语言，咱们能够给系统定一个一个一劳永逸、再也不修改的抽象层（或者接口），此设计能够有无穷无尽的行为实现层来实现。

在Java中咱们能够抽象出一个或者多个抽象类或者接口、规定出全部具体类（实现类）必须提供的方法特征做为系统设计的抽象层。这个抽象层预见了全部可能的扩展，所以在任何扩展状况下都不会改变。这就使系统的抽象层不须要修改，从而知足“开-闭”原则中的第二条：对修改关闭。

同时、因为从抽象层派生出一个或者多个具体实现类能够改变系统的行为。所以系统的设计对扩展是开放的，这就知足了“开-闭”原则的第一条。

要作到“开-闭”原则不是一件容易的事、可是也不是彻底无规律可循、这些规律也一样是以设计原则的身份出现，可是他们都是“开-闭”的手段和工具、是附属于“开-闭”的。

里氏代换原则、依赖倒转原则、合成/聚合复用原则、迪米特法则、接口隔离原则等。

2.二、里氏代换原则（LSP）

从“开-闭”原则中能够看出面向对象设计重要原则是建立抽象化。而且从抽象化导出具体化。

具体化能够给出不一样的版本，每个版本都给出不一样的实现（说直白点就是基类和子类的关系）。

从抽象化到具体化的导出要使用到继承关系和这里要引入的里氏代换原则。

什么是里氏代换原则？？？

一个软件实体若是使用的是一个基类的话，那么必定适用于其子类，并且它根本不能察觉出基类对象和子类对象的区别（也就是说，任何基类出现的地方均可以替换成子类）。

好比： 有两个类，一个是Base类，另外一个是Derived类，而且Derived类是Base类的子类。

那么一个方法若是能够接受一个基类对象base的话method(Base base)那么它必然能够接受一个子类对象derived,也就是method(Derived derived)。

注意：里氏代换原则反过来是没法实现的。

2.三、依赖倒转原则（DIP）

实现“开-闭”原则的关键是抽象化、而且从抽象化导出具体实现，如说“开-闭”是面向对象设计的目标的话，依赖倒转原则是面向对象的设计的主要机制。
依赖倒转原则讲的是： 要依赖于抽象，不要依赖于具体。

什么是依赖倒转原则？？？

简单的说，依赖倒转原则要求客户依赖抽象耦合。

依赖倒转原则表述的是；细节应当依赖于抽象。

其另外一种表述是：要针对接口编程，不要针对实现编程，

针对接口编程意思是说，应当使用Java接口和抽象类进行变量的类型声明、参量的类型声明、方法的返回类型声明、以及数据类型的转换等。

不要针对实现编程的意思是说：不该当使用具体类进行变量的类型声明、参量的类型声明、方法的返回类型声明、以及数据类型的转换等。

要保证作到这一点，一个具体的Java 类应当只实现Java接口或者抽象类中声明过的方法，而不该当有多余的方法。

倒转依赖关系强调一个系统内的实体之间的关系的灵活性。基本上，若是设计师但愿遵照“开-闭”原则，那么倒转依赖原则即是达到要求的途径。

2.四、接口隔离原则(ISP)

接口隔离原则讲的是：使用多个专门的接口比使用单一总接口要好。换而言之，从一个客户类的角度来说，一个类对另外一个的依赖性应当创建在最小的接口上

什么是接口隔离原则？？？

使用多个专门的接口比使用单一的总接口要好

一个类对另一个类的依赖性应当是创建在最小的接口上的。

一个接口表明一个角色，不该当将不一样的角色都交给一个接口。

没有关系的接口合并在一块儿，造成一个臃肿的大接口，这是对角色和接口的污染。“不该该强迫客户依赖于它们不用的方法。

接口属于客户，不属于它所在的类层次结构。”这个说得很明白了，再通俗点说，不要强迫客户使用它们不用的方法，若是强迫用户使用它们不使用的方法，那么这些客户就会面临因为这些不使用的方法的改变所带来的改变。

2.五、合成/聚合复用原则（CARP）

合成/聚合复用原则常常又叫作合成复用原则。合成/聚合复用原则就是在一个新对象里面使用一个已经存在的对象，使之成为新对象的一部分，新对象经过向这些对象委派达到复用功能的目的。
这个设计原则有另外一个更简单的表述： 要进尽可能使用合成/聚合，尽可能不要使用继承。

合成一词使用比较普遍，常常用易引发混淆。为了不混淆咱们来简单的考察下"合成"和“聚合”的区别

1: 合成和聚合均是关联的特殊种类。
2: 聚合用来表示“拥有”关系或者总体与部分的关系、同时部分能够单独存在。
3: 合成则表示一种强的多的“拥有”关系，部分和总体的生命周期是一致的，部分离开总体没法单独存活的。好比人是一个总体各个肢体是部分。

2.六、迪米特法则（LoD）

迪米特法则又叫最少知道原则，就是说，一个对象应当对其余对象有尽量少的了解。

迪米特法则最初是用来做为面向对象的系统设计风格的一种法则，1987年秋天由 Ian Holland 在美国东北大学为一个叫迪米特的项目设计提出的。所以叫作迪米特法则。

迪米特法则的各类表述

没有任何一个其它的OO设计原则像迪米特法则这样有如此之多的表述方式，下面是几种有表明性的表述。

1: 只与你直接的朋友通讯
2: 不要跟“陌生人”说话
3: 每个软件单位对其的单位都只有最少的了解，并且局限于哪些与本单位密切相关的软件单位。

在上面表述中里面，什么是“直接“，”陌生“和”密切“则被有意识的模糊化了，以便在不一样的环境下能够有不一样的解释。

总结

这些设计原则都是软件工程里面很基础也很重要的部分，也是咱们开发人员最容易忽略的部分。

做为面试官的几年里，应聘者能完整答上来设计模式的几大原则或者面向对象设计原则的太少了（包括一些高级和资深）。

若是这几大原则没有吃透的话，是不可能设计出一个好的软件系统的。写这篇的目的也在于本身回顾加深一下理解。