在我们学习的23种模式中,每个模式都是按照设计模式的六大原则而设计的,只不过是每种模式体现的原
则的侧重点不同,下面我们来介绍一下这六大原则
一、分述
1.单一职责原则
对于一个类,应该仅有一个引起它变化的原因;当发生引起一个类变化的原因有很多的时候,那么这
个
类就会与其他类的耦合性增强,这样对于系统的维护是很不利的,也不符合设计软件低耦合的思想
单例模式是能很好体现单一职责原则的模式
它保证了一个类仅能产生一个实例,并且只提供一个访问他的全局访问点
![](https://img-blog.csdn.net/20141221153039342?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvaHVzZW4xMzE0/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
但是有人会问了,尽管他只能在某一时间做一件事,但是当有多个类都要调用他的时候该怎么办?不
用担心,我们可以给他加锁,当有多个对象访问时,只会有一个线程进入加锁的代码,其他线程都在等待
直到该对象被释放才会有下一个线程进入
2.开放-封闭原则
定义:对扩展开放,对修改关闭
工厂方法可以很好的体现这一原则:
![](https://img-blog.csdn.net/20141221153539720?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvaHVzZW4xMzE0/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
在工厂方法中,如果要扩展功能,只需在ProducFactory下增加类工厂即可,但是它对于修改是关闭
的,因为如果要修改一个类,会影响该类的父类和调用它的那些类
3.依赖倒转原则(接口应用比较广泛)
定义:高层模块不应该依赖底层模块,两个都应该依赖于抽象;
抽象不应该依赖细节,细节应该依赖抽象(针对接口编程,不要针对实现编程)
在音乐解释器模式中,音符音节音速都继承于抽象的表达式,而演奏内容的实现依赖与抽象的表达式
类,这样当我们改变具体累音符音节音速甚至是增加音量类时都可以直接添加
4.里氏转换原则
定义:子类必须能够替换它的父类
![](https://img-blog.csdn.net/20141221154840390?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvaHVzZW4xMzE0/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
在上图模版方法中,抽象类中的抽象的行为要放到子类中去实现,当其他类调用抽象类的方法时,我
们可以直接让这个类调用某一具体类,而系统察觉不出这种变化
5.迪米特法则
定义:如果两个类不必彼此直接通信,那么这两个类就不应当直接发生相互作用。如果其中一个类需
要调用另一个类的方法的话,可以通过第三个类转发这个调用(尽量减少两个类之间的关系)
![](https://img-blog.csdn.net/20141221155249946?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvaHVzZW4xMzE0/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
在代理模式中,追求者通过代理转发自己送给心爱女孩礼物,这样追求者类就与女孩类的关系减少,
耦合性就降低了
6.合成聚合复用原则
这个原则我们在UML中就接触过:合成是一种强的拥有关系,如鸟拥有翅膀,翅膀也是鸟身体的一部
分;聚合是一种弱拥有的关系,如汽车拥有发动机,但发动机不一定是汽车的一部分
通过合成和聚合可以实现代码的复用,也可以有效降低类之间的耦合性;尽量少的使用继承实现代码
的复用,因为继承会造成基类与子类之间的耦合性增强,不利于维护
二、比较
里氏代换原则强调子类与父类之间的复用关系
单一职责原则强调类的内聚性要强
其他原则强调类之间的耦合性要低
三、小结
六个原则在每个模式中都有体现只不过是侧重点不同而已
用好设计模式可以提高代码的效率,更加容易的扩展功能,也会更加的好维护