精华内容
下载资源
问答
  • 软件设计模式六大原则

    千次阅读 2019-08-29 09:28:16
    设计模式六大原则(1):单一职责原则 设计模式六大原则(2):里氏替换原则 设计模式六大原则(3):依赖倒置原则 设计模式六大原则(4):接口隔离原则 设计模式六大原则(5):迪米特法则 设计模式六大原则...
    1. 设计模式六大原则(1):单一职责原则
    2. 设计模式六大原则(2):里氏替换原则
    3. 设计模式六大原则(3):依赖倒置原则
    4. 设计模式六大原则(4):接口隔离原则
    5. 设计模式六大原则(5):迪米特法则
    6. 设计模式六大原则(6):开闭原则

    设计模式六大原则(1):单一职责原则

    定义:不要存在多于一个导致类变更的原因。通俗的说,即一个类只负责一项职责。 
    问题由来:类T负责两个不同的职责:职责P1,职责P2。当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障。

    解决方案:遵循单一职责原则。分别建立两个类T1、T2,使T1完成职责P1功能,T2完成职责P2功能。这样,当修改类T1时,不会使职责P2发生故障风险;同理,当修改T2时,也不会使职责P1发生故障风险。

    说到单一职责原则,很多人都会不屑一顾。因为它太简单了。稍有经验的程序员即使从来没有读过设计模式、从来没有听说过单一职责原则,在设计软件时也会自觉的遵守这一重要原则,因为这是常识。在软件编程中,谁也不希望因为修改了一个功能导致其他的功能发生故障。而避免出现这一问题的方法便是遵循单一职责原则。虽然单一职责原则如此简单,并且被认为是常识,但是即便是经验丰富的程序员写出的程序,也会有违背这一原则的代码存在。为什么会出现这种现象呢?因为有职责扩散。所谓职责扩散,就是因为某种原因,职责P被分化为粒度更细的职责P1和P2。

    比如:类T只负责一个职责P,这样设计是符合单一职责原则的。后来由于某种原因,也许是需求变更了,也许是程序的设计者境界提高了,需要将职责P细分为粒度更细的职责P1,P2,这时如果要使程序遵循单一职责原则,需要将类T也分解为两个类T1和T2,分别负责P1、P2两个职责。但是在程序已经写好的情况下,这样做简直太费时间了。所以,简单的修改类T,用它来负责两个职责是一个比较不错的选择,虽然这样做有悖于单一职责原则。(这样做的风险在于职责扩散的不确定性,因为我们不会想到这个职责P,在未来可能会扩散为P1,P2,P3,P4……Pn。所以记住,在职责扩散到我们无法控制的程度之前,立刻对代码进行重构。)

    举例说明,用一个类描述动物呼吸这个场景:

    class Animal{
    	public void breathe(String animal){
    		System.out.println(animal+"呼吸空气");
    	}
    }
    public class Client{
    	public static void main(String[] args){
    		Animal animal = new Animal();
    		animal.breathe("牛");
    		animal.breathe("羊");
    		animal.breathe("猪");
    	}
    } 

    运行结果:

    牛呼吸空气

    羊呼吸空气

    猪呼吸空气

    程序上线后,发现问题了,并不是所有的动物都呼吸空气的,比如鱼就是呼吸水的。修改时如果遵循单一职责原则,需要将Animal类细分为陆生动物类Terrestrial,水生动物Aquatic,代码如下:

    class Terrestrial{
    	public void breathe(String animal){
    		System.out.println(animal+"呼吸空气");
    	}
    }
    class Aquatic{
    	public void breathe(String animal){
    		System.out.println(animal+"呼吸水");
    	}
    }
    
    public class Client{
    	public static void main(String[] args){
    		Terrestrial terrestrial = new Terrestrial();
    		terrestrial.breathe("牛");
    		terrestrial.breathe("羊");
    		terrestrial.breathe("猪");
    		
    		Aquatic aquatic = new Aquatic();
    		aquatic.breathe("鱼");
    	}
    }

    运行结果:

    牛呼吸空气

    羊呼吸空气

    猪呼吸空气

    鱼呼吸水

    我们会发现如果这样修改花销是很大的,除了将原来的类分解之外,还需要修改客户端。而直接修改类Animal来达成目的虽然违背了单一职责原则,但花销却小的多,代码如下

    class Animal{
    	public void breathe(String animal){
    		if("鱼".equals(animal)){
    			System.out.println(animal+"呼吸水");
    		}else{
    			System.out.println(animal+"呼吸空气");
    		}
    	}
    }
    
    public class Client{
    	public static void main(String[] args){
    		Animal animal = new Animal();
    		animal.breathe("牛");
    		animal.breathe("羊");
    		animal.breathe("猪");
    		animal.breathe("鱼");
    	}
    } 

    可以看到,这种修改方式要简单的多。但是却存在着隐患:有一天需要将鱼分为呼吸淡水的鱼和呼吸海水的鱼,则又需要修改Animal类的breathe方法,而对原有代码的修改会对调用“猪”“牛”“羊”等相关功能带来风险,也许某一天你会发现程序运行的结果变为“牛呼吸水”了。这种修改方式直接在代码级别上违背了单一职责原则,虽然修改起来最简单,但隐患却是最大的。还有一种修改方式:

    class Animal{
    	public void breathe(String animal){
    		System.out.println(animal+"呼吸空气");
    	}
    
    	public void breathe2(String animal){
    		System.out.println(animal+"呼吸水");
    	}
    }
    
    public class Client{
    	public static void main(String[] args){
    		Animal animal = new Animal();
    		animal.breathe("牛");
    		animal.breathe("羊");
    		animal.breathe("猪");
    		animal.breathe2("鱼");
    	}
    } 

    可以看到,这种修改方式没有改动原来的方法,而是在类中新加了一个方法,这样虽然也违背了单一职责原则,但在方法级别上却是符合单一职责原则的,因为它并没有动原来方法的代码。这三种方式各有优缺点,那么在实际编程中,采用哪一中呢?其实这真的比较难说,需要根据实际情况来确定。我的原则是:只有逻辑足够简单,才可以在代码级别上违反单一职责原则;只有类中方法数量足够少,才可以在方法级别上违反单一职责原则;

    例如本文所举的这个例子,它太简单了,它只有一个方法,所以,无论是在代码级别上违反单一职责原则,还是在方法级别上违反,都不会造成太大的影响。实际应用中的类都要复杂的多,一旦发生职责扩散而需要修改类时,除非这个类本身非常简单,否则还是遵循单一职责原则的好。

    遵循单一职责原的优点有:

    • 可以降低类的复杂度,一个类只负责一项职责,其逻辑肯定要比负责多项职责简单的多;
    • 提高类的可读性,提高系统的可维护性;
    • 变更引起的风险降低,变更是必然的,如果单一职责原则遵守的好,当修改一个功能时,可以显著降低对其他功能的影响。

    需要说明的一点是单一职责原则不只是面向对象编程思想所特有的,只要是模块化的程序设计,都适用单一职责原则。

    设计模式六大原则(2):里氏替换原则

    肯定有不少人跟我刚看到这项原则的时候一样,对这个原则的名字充满疑惑。其实原因就是这项原则最早是在1988年,由麻省理工学院的一位姓里的女士(Barbara Liskov)提出来的。

    定义1:如果对每一个类型为 T1的对象 o1,都有类型为 T2 的对象o2,使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时,程序 P 的行为没有发生变化,那么类型 T2 是类型 T1 的子类型。

    定义2:所有引用基类的地方必须能透明地使用其子类的对象。

    问题由来:有一功能P1,由类A完成。现需要将功能P1进行扩展,扩展后的功能为P,其中P由原有功能P1与新功能P2组成。新功能P由类A的子类B来完成,则子类B在完成新功能P2的同时,有可能会导致原有功能P1发生故障。

    解决方案:当使用继承时,遵循里氏替换原则。类B继承类A时,除添加新的方法完成新增功能P2外,尽量不要重写父类A的方法,也尽量不要重载父类A的方法。

    继承包含这样一层含义:父类中凡是已经实现好的方法(相对于抽象方法而言),实际上是在设定一系列的规范和契约,虽然它不强制要求所有的子类必须遵从这些契约,但是如果子类对这些非抽象方法任意修改,就会对整个继承体系造成破坏。而里氏替换原则就是表达了这一层含义。

    继承作为面向对象三大特性之一,在给程序设计带来巨大便利的同时,也带来了弊端。比如使用继承会给程序带来侵入性,程序的可移植性降低,增加了对象间的耦合性,如果一个类被其他的类所继承,则当这个类需要修改时,必须考虑到所有的子类,并且父类修改后,所有涉及到子类的功能都有可能会产生故障。

    举例说明继承的风险,我们需要完成一个两数相减的功能,由类A来负责。

    class A{
    	public int func1(int a, int b){
    		return a-b;
    	}
    }
    
    public class Client{
    	public static void main(String[] args){
    		A a = new A();
    		System.out.println("100-50="+a.func1(100, 50));
    		System.out.println("100-80="+a.func1(100, 80));
    	}
    } 

    运行结果:

    100-50=50

    100-80=20

    后来,我们需要增加一个新的功能:完成两数相加,然后再与100求和,由类B来负责。即类B需要完成两个功能:

    • 两数相减。
    • 两数相加,然后再加100。

    由于类A已经实现了第一个功能,所以类B继承类A后,只需要再完成第二个功能就可以了,代码如下:

    class B extends A{
    	public int func1(int a, int b){
    		return a+b;
    	}
    	
    	public int func2(int a, int b){
    		return func1(a,b)+100;
    	}
    }
    
    public class Client{
    	public static void main(String[] args){
    		B b = new B();
    		System.out.println("100-50="+b.func1(100, 50));
    		System.out.println("100-80="+b.func1(100, 80));
    		System.out.println("100+20+100="+b.func2(100, 20));
    	}
    } 

    类B完成后,运行结果:

    100-50=150

    100-80=180

    100+20+100=220

    我们发现原本运行正常的相减功能发生了错误。原因就是类B在给方法起名时无意中重写了父类的方法,造成所有运行相减功能的代码全部调用了类B重写后的方法,造成原本运行正常的功能出现了错误。在本例中,引用基类A完成的功能,换成子类B之后,发生了异常。在实际编程中,我们常常会通过重写父类的方法来完成新的功能,这样写起来虽然简单,但是整个继承体系的可复用性会比较差,特别是运用多态比较频繁时,程序运行出错的几率非常大。如果非要重写父类的方法,比较通用的做法是:原来的父类和子类都继承一个更通俗的基类,原有的继承关系去掉,采用依赖、聚合,组合等关系代替。

    里氏替换原则通俗的来讲就是:子类可以扩展父类的功能,但不能改变父类原有的功能。它包含以下4层含义:

    • 子类可以实现父类的抽象方法,但不能覆盖父类的非抽象方法。
    • 子类中可以增加自己特有的方法。
    • 当子类的方法重载父类的方法时,方法的前置条件(即方法的形参)要比父类方法的输入参数更宽松。
    • 当子类的方法实现父类的抽象方法时,方法的后置条件(即方法的返回值)要比父类更严格。

    看上去很不可思议,因为我们会发现在自己编程中常常会违反里氏替换原则,程序照样跑的好好的。所以大家都会产生这样的疑问,假如我非要不遵循里氏替换原则会有什么后果?

    后果就是:你写的代码出问题的几率将会大大增加。

    设计模式六大原则(3):依赖倒置原则

    定义:高层模块不应该依赖低层模块,二者都应该依赖其抽象;抽象不应该依赖细节;细节应该依赖抽象。

    问题由来:类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来达成。这种场景下,类A一般是高层模块,负责复杂的业务逻辑;类B和类C是低层模块,负责基本的原子操作;假如修改类A,会给程序带来不必要的风险。

    解决方案:将类A修改为依赖接口I,类B和类C各自实现接口I,类A通过接口I间接与类B或者类C发生联系,则会大大降低修改类A的几率。

    依赖倒置原则基于这样一个事实:相对于细节的多变性,抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。在java中,抽象指的是接口或者抽象类,细节就是具体的实现类,使用接口或者抽象类的目的是制定好规范和契约,而不去涉及任何具体的操作,把展现细节的任务交给他们的实现类去完成。

    依赖倒置原则的核心思想是面向接口编程,我们依旧用一个例子来说明面向接口编程比相对于面向实现编程好在什么地方。场景是这样的,母亲给孩子讲故事,只要给她一本书,她就可以照着书给孩子讲故事了。代码如下:

    运行结果:

    妈妈开始讲故事

    很久很久以前有一个阿拉伯的故事……

    运行良好,假如有一天,需求变成这样:不是给书而是给一份报纸,让这位母亲讲一下报纸上的故事,报纸的代码如下:

    class Newspaper{
    	public String getContent(){
    		return "林书豪38+7领导尼克斯击败湖人……";
    	}
    } 

    这位母亲却办不到,因为她居然不会读报纸上的故事,这太荒唐了,只是将书换成报纸,居然必须要修改Mother才能读。假如以后需求换成杂志呢?换成网页呢?还要不断地修改Mother,这显然不是好的设计。原因就是Mother与Book之间的耦合性太高了,必须降低他们之间的耦合度才行。

    我们引入一个抽象的接口IReader。读物,只要是带字的都属于读物:

    interface IReader{
    	public String getContent();
    } 

    Mother类与接口IReader发生依赖关系,而Book和Newspaper都属于读物的范畴,他们各自都去实现IReader接口,这样就符合依赖倒置原则了,代码修改为:

    class Newspaper implements IReader {
    	public String getContent(){
    		return "林书豪17+9助尼克斯击败老鹰……";
    	}
    }
    class Book implements IReader{
    	public String getContent(){
    		return "很久很久以前有一个阿拉伯的故事……";
    	}
    }
    
    class Mother{
    	public void narrate(IReader reader){
    		System.out.println("妈妈开始讲故事");
    		System.out.println(reader.getContent());
    	}
    }
    
    public class Client{
    	public static void main(String[] args){
    		Mother mother = new Mother();
    		mother.narrate(new Book());
    		mother.narrate(new Newspaper());
    	}
    }

    运行结果:

    妈妈开始讲故事

    很久很久以前有一个阿拉伯的故事……

    妈妈开始讲故事

    林书豪17+9助尼克斯击败老鹰……

    这样修改后,无论以后怎样扩展Client类,都不需要再修改Mother类了。这只是一个简单的例子,实际情况中,代表高层模块的Mother类将负责完成主要的业务逻辑,一旦需要对它进行修改,引入错误的风险极大。所以遵循依赖倒置原则可以降低类之间的耦合性,提高系统的稳定性,降低修改程序造成的风险。

    采用依赖倒置原则给多人并行开发带来了极大的便利,比如上例中,原本Mother类与Book类直接耦合时,Mother类必须等Book类编码完成后才可以进行编码,因为Mother类依赖于Book类。修改后的程序则可以同时开工,互不影响,因为Mother与Book类一点关系也没有。参与协作开发的人越多、项目越庞大,采用依赖导致原则的意义就越重大。现在很流行的TDD开发模式就是依赖倒置原则最成功的应用。

    传递依赖关系有三种方式,以上的例子中使用的方法是接口传递,另外还有两种传递方式:构造方法传递和setter方法传递,相信用过Spring框架的,对依赖的传递方式一定不会陌生。

    在实际编程中,我们一般需要做到如下3点:

    • 低层模块尽量都要有抽象类或接口,或者两者都有。
    • 变量的声明类型尽量是抽象类或接口。
    • 使用继承时遵循里氏替换原则。

    依赖倒置原则的核心就是要我们面向接口编程,理解了面向接口编程,也就理解了依赖倒置。

    设计模式六大原则(4):接口隔离原则

    定义:客户端不应该依赖它不需要的接口;一个类对另一个类的依赖应该建立在最小的接口上。 
    问题由来:类A通过接口I依赖类B,类C通过接口I依赖类D,如果接口I对于类A和类B来说不是最小接口,则类B和类D必须去实现他们不需要的方法。

    解决方案:将臃肿的接口I拆分为独立的几个接口,类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。

    举例来说明接口隔离原则:

    图1 未遵循接口隔离原则的设计)

    这个图的意思是:类A依赖接口I中的方法1、方法2、方法3,类B是对类A依赖的实现。类C依赖接口I中的方法1、方法4、方法5,类D是对类C依赖的实现。对于类B和类D来说,虽然他们都存在着用不到的方法(也就是图中红色字体标记的方法),但由于实现了接口I,所以也必须要实现这些用不到的方法。对类图不熟悉的可以参照程序代码来理解,代码如下:

    interface I {
    	public void method1();
    	public void method2();
    	public void method3();
    	public void method4();
    	public void method5();
    }
    
    class A{
    	public void depend1(I i){
    		i.method1();
    	}
    	public void depend2(I i){
    		i.method2();
    	}
    	public void depend3(I i){
    		i.method3();
    	}
    }
    
    class B implements I{
    	public void method1() {
    		System.out.println("类B实现接口I的方法1");
    	}
    	public void method2() {
    		System.out.println("类B实现接口I的方法2");
    	}
    	public void method3() {
    		System.out.println("类B实现接口I的方法3");
    	}
    	//对于类B来说,method4和method5不是必需的,但是由于接口A中有这两个方法,
    	//所以在实现过程中即使这两个方法的方法体为空,也要将这两个没有作用的方法进行实现。
    	public void method4() {}
    	public void method5() {}
    }
    
    class C{
    	public void depend1(I i){
    		i.method1();
    	}
    	public void depend2(I i){
    		i.method4();
    	}
    	public void depend3(I i){
    		i.method5();
    	}
    }
    
    class D implements I{
    	public void method1() {
    		System.out.println("类D实现接口I的方法1");
    	}
    	//对于类D来说,method2和method3不是必需的,但是由于接口A中有这两个方法,
    	//所以在实现过程中即使这两个方法的方法体为空,也要将这两个没有作用的方法进行实现。
    	public void method2() {}
    	public void method3() {}
    
    	public void method4() {
    		System.out.println("类D实现接口I的方法4");
    	}
    	public void method5() {
    		System.out.println("类D实现接口I的方法5");
    	}
    }
    
    public class Client{
    	public static void main(String[] args){
    		A a = new A();
    		a.depend1(new B());
    		a.depend2(new B());
    		a.depend3(new B());
    		
    		C c = new C();
    		c.depend1(new D());
    		c.depend2(new D());
    		c.depend3(new D());
    	}
    } 

    可以看到,如果接口过于臃肿,只要接口中出现的方法,不管对依赖于它的类有没有用处,实现类中都必须去实现这些方法,这显然不是好的设计。如果将这个设计修改为符合接口隔离原则,就必须对接口I进行拆分。在这里我们将原有的接口I拆分为三个接口,拆分后的设计如图2所示:

    (图2 遵循接口隔离原则的设计)

    照例贴出程序的代码,供不熟悉类图的朋友参考:

     interface I1 {
    	public void method1();
    }
    
    interface I2 {
    	public void method2();
    	public void method3();
    }
    
    interface I3 {
    	public void method4();
    	public void method5();
    }
    
    class A{
    	public void depend1(I1 i){
    		i.method1();
    	}
    	public void depend2(I2 i){
    		i.method2();
    	}
    	public void depend3(I2 i){
    		i.method3();
    	}
    }
    
    class B implements I1, I2{
    	public void method1() {
    		System.out.println("类B实现接口I1的方法1");
    	}
    	public void method2() {
    		System.out.println("类B实现接口I2的方法2");
    	}
    	public void method3() {
    		System.out.println("类B实现接口I2的方法3");
    	}
    }
    
    class C{
    	public void depend1(I1 i){
    		i.method1();
    	}
    	public void depend2(I3 i){
    		i.method4();
    	}
    	public void depend3(I3 i){
    		i.method5();
    	}
    }
    
    class D implements I1, I3{
    	public void method1() {
    		System.out.println("类D实现接口I1的方法1");
    	}
    	public void method4() {
    		System.out.println("类D实现接口I3的方法4");
    	}
    	public void method5() {
    		System.out.println("类D实现接口I3的方法5");
    	}
    } 

    接口隔离原则的含义是:建立单一接口,不要建立庞大臃肿的接口,尽量细化接口,接口中的方法尽量少。也就是说,我们要为各个类建立专用的接口,而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。本文例子中,将一个庞大的接口变更为3个专用的接口所采用的就是接口隔离原则。在程序设计中,依赖几个专用的接口要比依赖一个综合的接口更灵活。接口是设计时对外部设定的“契约”,通过分散定义多个接口,可以预防外来变更的扩散,提高系统的灵活性和可维护性。

    说到这里,很多人会觉的接口隔离原则跟之前的单一职责原则很相似,其实不然。其一,单一职责原则原注重的是职责;而接口隔离原则注重对接口依赖的隔离。其二,单一职责原则主要是约束类,其次才是接口和方法,它针对的是程序中的实现和细节;而接口隔离原则主要约束接口接口,主要针对抽象,针对程序整体框架的构建。

    采用接口隔离原则对接口进行约束时,要注意以下几点:

    • 接口尽量小,但是要有限度。对接口进行细化可以提高程序设计灵活性是不挣的事实,但是如果过小,则会造成接口数量过多,使设计复杂化。所以一定要适度。
    • 为依赖接口的类定制服务,只暴露给调用的类它需要的方法,它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务,才能建立最小的依赖关系。
    • 提高内聚,减少对外交互。使接口用最少的方法去完成最多的事情。

    运用接口隔离原则,一定要适度,接口设计的过大或过小都不好。设计接口的时候,只有多花些时间去思考和筹划,才能准确地实践这一原则。

    设计模式六大原则(5):迪米特法则

    定义:一个对象应该对其他对象保持最少的了解。

    问题由来:类与类之间的关系越密切,耦合度越大,当一个类发生改变时,对另一个类的影响也越大。

    解决方案:尽量降低类与类之间的耦合。

    自从我们接触编程开始,就知道了软件编程的总的原则:低耦合,高内聚。无论是面向过程编程还是面向对象编程,只有使各个模块之间的耦合尽量的低,才能提高代码的复用率。低耦合的优点不言而喻,但是怎么样编程才能做到低耦合呢?那正是迪米特法则要去完成的。

    迪米特法则又叫最少知道原则,最早是在1987年由美国Northeastern University的Ian Holland提出。通俗的来讲,就是一个类对自己依赖的类知道的越少越好。也就是说,对于被依赖的类来说,无论逻辑多么复杂,都尽量地的将逻辑封装在类的内部,对外除了提供的public方法,不对外泄漏任何信息。迪米特法则还有一个更简单的定义:只与直接的朋友通信。首先来解释一下什么是直接的朋友:每个对象都会与其他对象有耦合关系,只要两个对象之间有耦合关系,我们就说这两个对象之间是朋友关系。耦合的方式很多,依赖、关联、组合、聚合等。其中,我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友,而出现在局部变量中的类则不是直接的朋友。也就是说,陌生的类最好不要作为局部变量的形式出现在类的内部。

    举一个例子:有一个集团公司,下属单位有分公司和直属部门,现在要求打印出所有下属单位的员工ID。先来看一下违反迪米特法则的设计。

    //总公司员工
    class Employee{
    	private String id;
    	public void setId(String id){
    		this.id = id;
    	}
    	public String getId(){
    		return id;
    	}
    }
    
    //分公司员工
    class SubEmployee{
    	private String id;
    	public void setId(String id){
    		this.id = id;
    	}
    	public String getId(){
    		return id;
    	}
    }
    
    class SubCompanyManager{
    	public List<SubEmployee> getAllEmployee(){
    		List<SubEmployee> list = new ArrayList<SubEmployee>();
    		for(int i=0; i<100; i++){
    			SubEmployee emp = new SubEmployee();
    			//为分公司人员按顺序分配一个ID
    			emp.setId("分公司"+i);
    			list.add(emp);
    		}
    		return list;
    	}
    }
    
    class CompanyManager{
    
    	public List<Employee> getAllEmployee(){
    		List<Employee> list = new ArrayList<Employee>();
    		for(int i=0; i<30; i++){
    			Employee emp = new Employee();
    			//为总公司人员按顺序分配一个ID
    			emp.setId("总公司"+i);
    			list.add(emp);
    		}
    		return list;
    	}
    	
    	public void printAllEmployee(SubCompanyManager sub){
    		List<SubEmployee> list1 = sub.getAllEmployee();
    		for(SubEmployee e:list1){
    			System.out.println(e.getId());
    		}
    
    		List<Employee> list2 = this.getAllEmployee();
    		for(Employee e:list2){
    			System.out.println(e.getId());
    		}
    	}
    }
    
    public class Client{
    	public static void main(String[] args){
    		CompanyManager e = new CompanyManager();
    		e.printAllEmployee(new SubCompanyManager());
    	}
    } 

    现在这个设计的主要问题出在CompanyManager中,根据迪米特法则,只与直接的朋友发生通信,而SubEmployee类并不是CompanyManager类的直接朋友(以局部变量出现的耦合不属于直接朋友),从逻辑上讲总公司只与他的分公司耦合就行了,与分公司的员工并没有任何联系,这样设计显然是增加了不必要的耦合。按照迪米特法则,应该避免类中出现这样非直接朋友关系的耦合。修改后的代码如下:

    class SubCompanyManager{
    	public List<SubEmployee> getAllEmployee(){
    		List<SubEmployee> list = new ArrayList<SubEmployee>();
    		for(int i=0; i<100; i++){
    			SubEmployee emp = new SubEmployee();
    			//为分公司人员按顺序分配一个ID
    			emp.setId("分公司"+i);
    			list.add(emp);
    		}
    		return list;
    	}
    	public void printEmployee(){
    		List<SubEmployee> list = this.getAllEmployee();
    		for(SubEmployee e:list){
    			System.out.println(e.getId());
    		}
    	}
    }
    
    class CompanyManager{
    	public List<Employee> getAllEmployee(){
    		List<Employee> list = new ArrayList<Employee>();
    		for(int i=0; i<30; i++){
    			Employee emp = new Employee();
    			//为总公司人员按顺序分配一个ID
    			emp.setId("总公司"+i);
    			list.add(emp);
    		}
    		return list;
    	}
    	
    	public void printAllEmployee(SubCompanyManager sub){
    		sub.printEmployee();
    		List<Employee> list2 = this.getAllEmployee();
    		for(Employee e:list2){
    			System.out.println(e.getId());
    		}
    	}
    }

    修改后,为分公司增加了打印人员ID的方法,总公司直接调用来打印,从而避免了与分公司的员工发生耦合。

    迪米特法则的初衷是降低类之间的耦合,由于每个类都减少了不必要的依赖,因此的确可以降低耦合关系。但是凡事都有度,虽然可以避免与非直接的类通信,但是要通信,必然会通过一个“中介”来发生联系,例如本例中,总公司就是通过分公司这个“中介”来与分公司的员工发生联系的。过分的使用迪米特原则,会产生大量这样的中介和传递类,导致系统复杂度变大。所以在采用迪米特法则时要反复权衡,既做到结构清晰,又要高内聚低耦合。

    设计模式六大原则(6):开闭原则 

    定义:一个软件实体如类、模块和函数应该对扩展开放,对修改关闭。

    问题由来:在软件的生命周期内,因为变化、升级和维护等原因需要对软件原有代码进行修改时,可能会给旧代码中引入错误,也可能会使我们不得不对整个功能进行重构,并且需要原有代码经过重新测试。

    解决方案:当软件需要变化时,尽量通过扩展软件实体的行为来实现变化,而不是通过修改已有的代码来实现变化。

    开闭原则是面向对象设计中最基础的设计原则,它指导我们如何建立稳定灵活的系统。开闭原则可能是设计模式六项原则中定义最模糊的一个了,它只告诉我们对扩展开放,对修改关闭,可是到底如何才能做到对扩展开放,对修改关闭,并没有明确的告诉我们。以前,如果有人告诉我“你进行设计的时候一定要遵守开闭原则”,我会觉的他什么都没说,但貌似又什么都说了。因为开闭原则真的太虚了。

    在仔细思考以及仔细阅读很多设计模式的文章后,终于对开闭原则有了一点认识。其实,我们遵循设计模式前面5大原则,以及使用23种设计模式的目的就是遵循开闭原则。也就是说,只要我们对前面5项原则遵守的好了,设计出的软件自然是符合开闭原则的,这个开闭原则更像是前面五项原则遵守程度的“平均得分”,前面5项原则遵守的好,平均分自然就高,说明软件设计开闭原则遵守的好;如果前面5项原则遵守的不好,则说明开闭原则遵守的不好。

    其实笔者认为,开闭原则无非就是想表达这样一层意思:用抽象构建框架,用实现扩展细节。因为抽象灵活性好,适应性广,只要抽象的合理,可以基本保持软件架构的稳定。而软件中易变的细节,我们用从抽象派生的实现类来进行扩展,当软件需要发生变化时,我们只需要根据需求重新派生一个实现类来扩展就可以了。当然前提是我们的抽象要合理,要对需求的变更有前瞻性和预见性才行。

    说到这里,再回想一下前面说的5项原则,恰恰是告诉我们用抽象构建框架,用实现扩展细节的注意事项而已:单一职责原则告诉我们实现类要职责单一;里氏替换原则告诉我们不要破坏继承体系;依赖倒置原则告诉我们要面向接口编程;接口隔离原则告诉我们在设计接口的时候要精简单一;迪米特法则告诉我们要降低耦合。而开闭原则是总纲,他告诉我们要对扩展开放,对修改关闭。

    最后说明一下如何去遵守这六个原则。对这六个原则的遵守并不是是和否的问题,而是多和少的问题,也就是说,我们一般不会说有没有遵守,而是说遵守程度的多少。任何事都是过犹不及,设计模式的六个设计原则也是一样,制定这六个原则的目的并不是要我们刻板的遵守他们,而需要根据实际情况灵活运用。对他们的遵守程度只要在一个合理的范围内,就算是良好的设计。我们用一幅图来说明一下。

    图中的每一条维度各代表一项原则,我们依据对这项原则的遵守程度在维度上画一个点,则如果对这项原则遵守的合理的话,这个点应该落在红色的同心圆内部;如果遵守的差,点将会在小圆内部;如果过度遵守,点将会落在大圆外部。一个良好的设计体现在图中,应该是六个顶点都在同心圆中的六边形。

    在上图中,设计1、设计2属于良好的设计,他们对六项原则的遵守程度都在合理的范围内;设计3、设计4设计虽然有些不足,但也基本可以接受;设计5则严重不足,对各项原则都没有很好的遵守;而设计6则遵守过渡了,设计5和设计6都是迫切需要重构的设计。

    到这里,设计模式的六大原则就写完了。主要参考书籍有《设计模式》《设计模式之禅》《大话设计模式》以及网上一些零散的文章,但主要内容主要还是我本人对这六个原则的感悟。写出来的目的一方面是对这六项原则系统地整理一下,一方面也与广大的网友分享,因为设计模式对编程人员来说,的确非常重要。正如有句话叫做一千个读者眼中有一千个哈姆雷特,如果大家对这六项原则的理解跟我有所不同,欢迎留言,大家共同探讨。

    展开全文
  • 设计模式六大原则

    万次阅读 多人点赞 2019-05-16 17:50:03
    一、单一职责原则(Single Responsibility Principle) 二.开闭原则(Open-Closed Principle, OCP) 三、里氏代换原则(Liskov Substitution Principle, LSP) 四、依赖倒置原则(Dependence Inversion Principle,...

    目录

     

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

    二.开闭原则(Open-Closed Principle, OCP)

    三、里氏代换原则(Liskov Substitution Principle, LSP)

    四、依赖倒置原则(Dependence Inversion Principle,DIP)

    五、接口隔离原则(Interface  Segregation Principle, ISP)

    六、迪米特法则(Law of  Demeter, LoD)

    总结


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

    定义:一个类只负责一个功能领域中的相应职责,或者可以定义为:就一个类而言,应该只有一个引起它变化的原因。

    问题由来:类T负责两个不同的职责:职责P1,职责P2。当由于职责P1需求发生改变而需要修改类T时,有 
    可能会导致原本运行正常的职责P2功能发生故障。

    单一职责原则告诉我们:一个类不能太“累”!在软件系统中,一个类(大到模块,小到方法)承担的职责越多,它被复用的可能性就越小,而且一个类承担的职责过多,就相当于将这些职责耦合在一起,当其中一个职责变化时,可能会影响其他职责的运作,因此要将这些职责进行分离,将不同的职责封装在不同的类中,即将不同的变化原因封装在不同的类中,如果多个职责总是同时发生改变则可将它们封装在同一类中。

    单一职责原则是实现高内聚、低耦合的指导方针,它是最简单但又最难运用的原则,需要设计人员发现类的不同职责并将其分离,而发现类的多重职责需要设计人员具有较强的分析设计能力和相关实践经验。

    SRP在类或接口中的使用:

    /**
    上面的的类图对应的接口入下
    */
    public interface IPhone{
      //拨通电话
      public void dial(String phoneNumber);
    
      //通话
      public void chat(Object o);
    
      //挂断电话
      public void hangup();
    }
    

    在看到这个接口的时候,我们都会认为这样的设计是没有问题的,拨通电话,通话,挂断电话写在同一个接口里面并没有什么错。但是,我们仔细分析,这个接口真的没有问题吗?单一职责原则要求一个接口或类只有一个原因引起变化,也就是说一个接口或一个类只有一个原则,它就只负责一件事。 但我们分析上面这个接口,却发现它包含了两个职责:一个时协议管理,一个是数据传送。dial()和hangup()两个方法实现的是协议管理,分别是拨通电话和挂机。chat()实现的是数据传送,把我们说的话转换成模拟信号或数字信号传递给对方,然后再把对方传递过来的信号还原成我们听得懂的语言。这里的协议接通和数据传送的变化都会引起该接口或实现类的变化。我们想一想,这两个职责会相互影响吗?不管是什么协议,协议接通只负责将电话接通就行,而数据传输只需要传输数据,不必要去管协议是如何接通的。所以通过分析,IPhone接口包含了两个职责,而且这两个职责的变化不互相影响,这就可以考虑分成两个接口。

    笼统地讲:是否需要拆分取决于变化:

    当变化发生,只影响其中一个职责,那就需要拆分

    如果变化都影响到这两个职责,那就不需要拆分。

    SRP也适用于方法:

    其实,单一职责原则不仅适用于类,接口,同样适用于方法中。这要举一个例子了,比如我们做项目的时候会遇到修改用户信息这样的功能模块,我们一般的想法是将用户的所有数据都接收过来,比如用户名,信息,密码,家庭地址等等,然后统一封装到一个User对象中提交到数据库,我们一般都是这么干的,就如下面这样:

    其实这样的方法是不可取的,因为职责不明确,方法不明确,你到底是要修改密码,还是修改用户名,还是修改地址,还是都要修改?这样职责不明确的话在与其他项目成员沟通的时候会产生很多麻烦,正确的设计如下:

    循单一职责原的优点有:

     1.可以降低类的复杂度,一个类只负责一项职责,其逻辑肯定要比负责多项职责简单的多;

     2. 提高类的可读性,提高系统的可维护性;

     3.变更引起的风险降低,变更是必然的,如果单一职责原则遵守的好,当修改一个功能时,可以显著降低对其他功能的影响。

    二.开闭原则(Open-Closed Principle, OCP)

    定义:一个软件实体应当对扩展开放,对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展

    问题由来:任何软件都需要面临一个很重要的问题,即它们的需求会随时间的推移而发生变化。因为变化,升级和维护等原因,如果需要对软件原有代码进行修改,可能会给旧代码引入错误,也有可能会使我们不得不对整个功能进行重构,并且需要原有代码经过重新测试,所以当软件需要变化时,尽量通过扩展软件实体的行为来实现变化,而不是通过修改已有的代码来实现使我们需要的。

    为了满足开闭原则,需要对系统进行抽象化设计,抽象化是开闭原则的关键。在Java、C#等编程语言中,可以为系统定义一个相对稳定的抽象层,而将不同的实现行为移至具体的实现层中完成。如果需要修改系统的行为,无须对抽象层进行任何改动,只需要增加新的具体类来实现新的业务功能即可,实现在不修改已有代码的基础上扩展系统的功能,达到开闭原则的要求。

    举例:

     实现画图表的功能,如饼状图和柱状图等,为了支持多种图表显示方式,原始设计方案如图下图所示:

    在ChartDisplay类的display()方法中存在如下代码片段:

    ......
    if (type.equals("pie")) {
    PieChart chart = new PieChart();
    chart.display();
    }
    else if (type.equals("bar")) {
    BarChart chart = new BarChart();
    chart.display();
    }
    ......

    在该代码中,如果需要增加一个新的图表类,如折线图LineChart,则需要修改ChartDisplay类的display()方法的源代码,增加新的判断逻辑,违反了开闭原则。

          现对该系统进行重构,使之符合开闭原则。

          (1) 增加一个抽象图表类AbstractChart,将各种具体图表类作为其子类;

          (2)  ChartDisplay类针对抽象图表类进行编程,由客户端来决定使用哪种具体图表。

          重构后结构如图2所示:

    我们引入了抽象图表类AbstractChart,且ChartDisplay针对抽象图表类进行编程,并通过setChart()方法由客户端来设置实例化的具体图表对象,在ChartDisplay的display()方法中调用chart对象的display()方法显示图表。如果需要增加一种新的图表,如折线图LineChart,只需要将LineChart也作为AbstractChart的子类,在客户端向ChartDisplay中注入一个LineChart对象即可,无须修改现有类库的源代码。 

    为什么使用开闭原则:

    第一:开闭原则非常有名,只要是面向对象编程,在开发时都会强调开闭原则

    第二:开闭原则是最基础的设计原则,其它的五个设计原则都是开闭原则的具体形态,也就是说其它的五个设计原则是指导设计的工具和方法,而开闭原则才是其精神领袖。依照Java语言的称谓,开闭原则是抽象类,而其它的五个原则是具体的实现类。

    第三:开闭原则可以提高复用性

    在面向对象的设计中,所有的逻辑都是从原子逻辑组合而来,而不是在一个类中独立实现一套业务逻辑。只有这样的代码才可以复用,逻辑粒度越小,被复用的可能性越大。为什么要复用呢?复用可以减少代码的重复,避免相同的逻辑分散在多个角落,减少维护人员的工作量以及系统变化时产生bug的机会。怎么才能提高复用率呢?设计者需要缩小逻辑粒度,直到一个逻辑不可以分为止。

    第四:开闭原则可以提高维护性 

    一款软件量产后,维护人员的工作不仅仅对数据进行维护,还可能要对程序进行扩展,维护人员最乐意的事是扩展一个类,而不是修改一个类。让维护人员读懂原有代码,再进行修改,是一件非常痛苦的事情,不要让他在原有的代码海洋中游荡后再修改,那是对维护人员的折磨和摧残。

    第五:面向对象开发的要求 

    万物皆对象,我们要把所有的事物抽象成对象,然后针对对象进行操作,但是万物皆发展变化,有变化就要有策略去应对,怎么快速应对呢?这就需要在设计之初考虑到尽可能多变化的因素,然后留下接口,等待“可能”转变为“现实”。

    如何使用开闭原则

    第一:抽象约束 
        抽象是对一组事物的通用描述,没有具体的实现,也就表示它可以有非常多的可能性,可以跟随需求的变化而变化。因此,通过接口或抽象类可以约束一组可能变化的行为,并且能够实现对扩展开放,其包含三层含义:

    1.通过接口或抽象类约束扩散,对扩展进行边界限定,不允许出现在接口或抽象类中不存在的public方法。

    2.参数类型,引用对象尽量使用接口或抽象类,而不是实现类,这主要是实现里氏替换原则的一个要求

    3.抽象层尽量保持稳定,一旦确定就不要修改

    第二:元数据(metadata)控件模块行为 

    编程是一个很苦很累的活,那怎么才能减轻压力呢?答案是尽量使用元数据来控制程序的行为,减少重复开发。什么是元数据?用来描述环境和数据的数据,通俗的说就是配置参数,参数可以从文件中获得,也可以从数据库中获得。

    第三:制定项目章程 
        在一个团队中,建立项目章程是非常重要的,因为章程是所有开发人员都必须遵守的约定,对项目来说,约定优于配置。这比通过接口或抽象类进行约束效率更高,而扩展性一点也没有减少

    第四:封装变化 

     对变化封装包含两层含义:

    (1)将相同的变化封装到一个接口或抽象类中

    (2)将不同的变化封装到不同的接口或抽象类中,不应该有两个不同的变化出现在同一个接口或抽象类中。 封装变化,也就是受保护的变化,找出预计有变化或不稳定的点,我们为这些变化点创建稳定的接口。

    三、里氏代换原则(Liskov Substitution Principle, LSP)

    定义:里氏代换原则(Liskov Substitution Principle, LSP):所有引用基类(父类)的地方必须能透明地使用其子类的对象。

    继承优点

    代码共享,减少创建类的工作量,每个子类都拥有父类的方法和属性;提高代码的重用性;子类可以形似父类,但又异于父类;提高代码的可扩展性,实现父类的方法就可以“为所欲为”了;提高产品或项目的开放性。

    继承缺点

    继承是侵入性的。只要继承,就必须拥有父类的所有属性和方法;降低代码的灵活性。子类必须拥有父类的属性和方法;

    增强了耦合性。当父类的常量、变量和方法被修改时,必需要考虑子类的修改,而且在缺乏规范的环境下,这种修改可能带来非常糟糕的结果;大片的代码需要重构。

    克服继承的缺点——里氏替换原则

    从整体上来看,利大于弊。

    里氏代换原则告诉我们,在软件中将一个基类对象替换成它的子类对象,程序将不会产生任何错误和异常,反过来则不成立,如果一个软件实体使用的是一个子类对象的话,那么它不一定能够使用基类对象。例如:我喜欢动物,那我一定喜欢狗,因为狗是动物的子类;但是我喜欢狗,不能据此断定我喜欢动物,因为我并不喜欢老鼠,虽然它也是动物。

    里氏代换原则是实现开闭原则的重要方式之一,由于使用基类对象的地方都可以使用子类对象,因此在程序中尽量使用基类类型来对对象进行定义,而在运行时再确定其子类类型,用子类对象来替换父类对象。

    在使用里氏代换原则时需要注意如下几个问题:

     (1)子类的所有方法必须在父类中声明,或子类必须实现父类中声明的所有方法。根据里氏代换原则,为了保证系统的扩展性,在程序中通常使用父类来进行定义,如果一个方法只存在子类中,在父类中不提供相应的声明,则无法在以父类定义的对象中使用该方法。

    (2)  我们在运用里氏代换原则时,尽量把父类设计为抽象类或者接口,让子类继承父类或实现父接口,并实现在父类中声明的方法,运行时,子类实例替换父类实例,我们可以很方便地扩展系统的功能,同时无须修改原有子类的代码,增加新的功能可以通过增加一个新的子类来实现。里氏代换原则是开闭原则的具体实现手段之一。

    (3) Java语言中,在编译阶段,Java编译器会检查一个程序是否符合里氏代换原则,这是一个与实现无关的、纯语法意义上的检查,但Java编译器的检查是有局限的

    系统需要提供一个发送Email的功能,客户(Customer)可以分为VIP客户(VIPCustomer)和普通客户(CommonCustomer)两类,原始设计方案如图所示:

          在对系统进行进一步分析后发现,无论是普通客户还是VIP客户,发送邮件的过程都是相同的,也就是说两个send()方法中的代码重复,而且在本系统中还将增加新类型的客户。为了让系统具有更好的扩展性,同时减少代码重复,使用里氏代换原则对其进行重构。

          在本实例中,可以考虑增加一个新的抽象客户类Customer,而将CommonCustomer和VIPCustomer类作为其子类,邮件发送类EmailSender类针对抽象客户类Customer编程,根据里氏代换原则,能够接受基类对象的地方必然能够接受子类对象,因此将EmailSender中的send()方法的参数类型改为Customer,如果需要增加新类型的客户,只需将其作为Customer类的子类即可。重构后的结构如图所示:

            里氏代换原则是实现开闭原则的重要方式之一。在本实例中,在传递参数时使用基类对象,除此以外,在定义成员变量、定义局部变量、确定方法返回类型时都可使用里氏代换原则。针对基类编程,在程序运行时再确定具体子类。
     

    四、依赖倒置原则(Dependence Inversion Principle,DIP)

    定义:

    高层模块不应该依赖低层模块,两者都应该依赖其抽象;抽象不应该依赖细节,细节应该依赖抽象,其核心思想是:要面向接口编程,不要面向实现编程。

    依赖倒转原则要求我们在程序代码中传递参数时或在关联关系中,尽量引用层次高的抽象层类,即使用接口和抽象类进行变量类型声明、参数类型声明、方法返回类型声明,以及数据类型的转换等,而不要用具体类来做这些事情。为了确保该原则的应用,一个具体类应当只实现接口或抽象类中声明过的方法,而不要给出多余的方法,否则将无法调用到在子类中增加的新方法。

    在引入抽象层后,系统将具有很好的灵活性,在程序中尽量使用抽象层进行编程,而将具体类写在配置文件中,这样一来,如果系统行为发生变化,只需要对抽象层进行扩展,并修改配置文件,而无须修改原有系统的源代码,在不修改的情况下来扩展系统的功能,满足开闭原则的要求。

    在实现依赖倒转原则时,我们需要针对抽象层编程,而将具体类的对象通过依赖注入(DependencyInjection, DI)的方式注入到其他对象中,依赖注入是指当一个对象要与其他对象发生依赖关系时,通过抽象来注入所依赖的对象。常用的注入方式有三种,分别是:构造注入,设值注入(Setter注入)和接口注入。构造注入是指通过构造函数来传入具体类的对象,设值注入是指通过Setter方法来传入具体类的对象,而接口注入是指通过在接口中声明的业务方法来传入具体类的对象。这些方法在定义时使用的是抽象类型,在运行时再传入具体类型的对象,由子类对象来覆盖父类对象。

    依赖倒置原则的作用

    (1)依赖倒置原则可以降低类间的耦合性。

    (2)依赖倒置原则可以提高系统的稳定性。

    (3)依赖倒置原则可以减少并行开发引起的风险。

    (4)依赖倒置原则可以提高代码的可读性和可维护性。

    依赖倒置原则的实现方法

    依赖倒置原则的目的是通过要面向接口的编程来降低类间的耦合性,所以我们在实际编程中只要遵循以下4点,就能在项目中满足这个规则。

    (1)每个类尽量提供接口或抽象类,或者两者都具备。

    (2)变量的声明类型尽量是接口或者是抽象类。

    (3)任何类都不应该从具体类派生。

    (4)使用继承时尽量遵循里氏替换原则

    例子:

    现需要将存储在TXT或Excel文件中的客户信息转存到数据库中,因此需要进行数据格式转换。在客户数据操作类中将调用数据格式转换类的方法实现格式转换和数据库插入操作,初始设计方案结构如图所示:

          在编码实现图所示结构时,Sunny软件公司开发人员发现该设计方案存在一个非常严重的问题,由于每次转换数据时数据来源不一定相同,因此需要更换数据转换类,如有时候需要将TXTDataConvertor改为ExcelDataConvertor,此时,需要修改CustomerDAO的源代码,而且在引入并使用新的数据转换类时也不得不修改CustomerDAO的源代码,系统扩展性较差,违反了开闭原则,现需要对该方案进行重构。

          在本实例中,由于CustomerDAO针对具体数据转换类编程,因此在增加新的数据转换类或者更换数据转换类时都不得不修改CustomerDAO的源代码。我们可以通过引入抽象数据转换类解决该问题,在引入抽象数据转换类DataConvertor之后,CustomerDAO针对抽象类DataConvertor编程,而将具体数据转换类名存储在配置文件中,符合依赖倒转原则。根据里氏代换原则,程序运行时,具体数据转换类对象将替换DataConvertor类型的对象,程序不会出现任何问题。更换具体数据转换类时无须修改源代码,只需要修改配置文件;如果需要增加新的具体数据转换类,只要将新增数据转换类作为DataConvertor的子类并修改配置文件即可,原有代码无须做任何修改,满足开闭原则。重构后的结构如图所示:

          在上述重构过程中,我们使用了开闭原则、里氏代换原则和依赖倒转原则,在大多数情况下,这三个设计原则会同时出现,开闭原则是目标,里氏代换原则是基础,依赖倒转原则是手段,它们相辅相成,相互补充,目标一致,只是分析问题时所站角度不同而已。

    五、接口隔离原则(Interface  Segregation Principle, ISP)

    定义:使用多个专门的接口,而不使用单一的总接口,即客户端不应该依赖那些它不需要的接口。

    根据接口隔离原则,当一个接口太大时,我们需要将它分割成一些更细小的接口,使用该接口的客户端仅需知道与之相关的方法即可。每一个接口应该承担一种相对独立的角色,不干不该干的事,该干的事都要干。这里的“接口”往往有两种不同的含义:一种是指一个类型所具有的方法特征的集合,仅仅是一种逻辑上的抽象;另外一种是指某种语言具体的“接口”定义,有严格的定义和结构,比如Java语言中的interface。对于这两种不同的含义,ISP的表达方式以及含义都有所不同:

     (1) 当把“接口”理解成一个类型所提供的所有方法特征的集合的时候,这就是一种逻辑上的概念,接口的划分将直接带来类型的划分。可以把接口理解成角色,一个接口只能代表一个角色,每个角色都有它特定的一个接口,此时,这个原则可以叫做“角色隔离原则”。

    (2) 如果把“接口”理解成狭义的特定语言的接口,那么ISP表达的意思是指接口仅仅提供客户端需要的行为,客户端不需要的行为则隐藏起来,应当为客户端提供尽可能小的单独的接口,而不要提供大的总接口。在面向对象编程语言中,实现一个接口就需要实现该接口中定义的所有方法,因此大的总接口使用起来不一定很方便,为了使接口的职责单一,需要将大接口中的方法根据其职责不同分别放在不同的小接口中,以确保每个接口使用起来都较为方便,并都承担某一单一角色。接口应该尽量细化,同时接口中的方法应该尽量少,每个接口中只包含一个客户端(如子模块或业务逻辑类)所需的方法即可,这种机制也称为“定制服务”,即为不同的客户端提供宽窄不同的接口。

    接口隔离原则和单一职责都是为了提高类的内聚性、降低它们之间的耦合性,体现了封装的思想,但两者是不同的:

    (1)单一职责原则注重的是职责,而接口隔离原则注重的是对接口依赖的隔离。

    (2)单一职责原则主要是约束类,它针对的是程序中的实现和细节;接口隔离原则主要约束接口,主要针对抽象和程序整体框架的构建。

    接口隔离原则的优点

    接口隔离原则是为了约束接口、降低类对接口的依赖性,遵循接口隔离原则有以下 5 个优点。

    (1)将臃肿庞大的接口分解为多个粒度小的接口,可以预防外来变更的扩散,提高系统的灵活性和可维护性。

    (2)接口隔离提高了系统的内聚性,减少了对外交互,降低了系统的耦合性。

    (3)如果接口的粒度大小定义合理,能够保证系统的稳定性;但是,如果定义过小,则会造成接口数量过多,使设计复杂化;如果定义太大,灵活性降低,无法提供定制服务,给整体项目带来无法预料的风险。

    (4)使用多个专门的接口还能够体现对象的层次,因为可以通过接口的继承,实现对总接口的定义。

    (5)能减少项目工程中的代码冗余。过大的大接口里面通常放置许多不用的方法,当实现这个接口的时候,被迫设计冗余的代码。

    接口隔离原则的实现方法

    在具体应用接口隔离原则时,应该根据以下几个规则来衡量。

    (1)接口尽量小,但是要有限度。一个接口只服务于一个子模块或业务逻辑。

    (2)为依赖接口的类定制服务。只提供调用者需要的方法,屏蔽不需要的方法。

    (3)了解环境,拒绝盲从。每个项目或产品都有选定的环境因素,环境不同,接口拆分的标准就不同深入了解业务逻辑。

    (4)提高内聚,减少对外交互。使接口用最少的方法去完成最多的事情。

    下面通过一个简单实例来加深对接口隔离原则的理解:

    Sunny软件公司开发人员针对某CRM系统的客户数据显示模块设计了如图1所示接口,其中方法dataRead()用于从文件中读取数据,方法transformToXML()用于将数据转换成XML格式,方法createChart()用于创建图表,方法displayChart()用于显示图表,方法createReport()用于创建文字报表,方法displayReport()用于显示文字报表。

          在实际使用过程中发现该接口很不灵活,例如如果一个具体的数据显示类无须进行数据转换(源文件本身就是XML格式),但由于实现了该接口,将不得不实现其中声明的transformToXML()方法(至少需要提供一个空实现);如果需要创建和显示图表,除了需实现与图表相关的方法外,还需要实现创建和显示文字报表的方法,否则程序编译时将报错。

          现使用接口隔离原则对其进行重构。

          在图中,由于在接口CustomerDataDisplay中定义了太多方法,即该接口承担了太多职责,一方面导致该接口的实现类很庞大,在不同的实现类中都不得不实现接口中定义的所有方法,灵活性较差,如果出现大量的空方法,将导致系统中产生大量的无用代码,影响代码质量;另一方面由于客户端针对大接口编程,将在一定程序上破坏程序的封装性,客户端看到了不应该看到的方法,没有为客户端定制接口。因此需要将该接口按照接口隔离原则和单一职责原则进行重构,将其中的一些方法封装在不同的小接口中,确保每一个接口使用起来都较为方便,并都承担某一单一角色,每个接口中只包含一个客户端(如模块或类)所需的方法即可。

          通过使用接口隔离原则,本实例重构后的结构如图所示:

          在使用接口隔离原则时,我们需要注意控制接口的粒度,接口不能太小,如果太小会导致系统中接口泛滥,不利于维护;接口也不能太大,太大的接口将违背接口隔离原则,灵活性较差,使用起来很不方便。一般而言,接口中仅包含为某一类用户定制的方法即可,不应该强迫客户依赖于那些它们不用的方法。

    六、迪米特法则(Law of  Demeter, LoD)

     

    定义:迪米特法则(Law of  Demeter, LoD):一个软件实体应当尽可能少地与其他实体发生相互作用。

    迪米特法则(Law of Demeter,LoD)又叫作最少知识原则(Least Knowledge Principle,LKP),产生于 1987 年美国东北大学(Northeastern University)的一个名为迪米特(Demeter)的研究项目,由伊恩·荷兰(Ian Holland)提出,被 UML 创始者之一的布奇(Booch)普及,后来又因为在经典著作《程序员修炼之道》(The Pragmatic Programmer)提及而广为人知。

    迪米特法则的定义是:只与你的直接朋友交谈,不跟“陌生人”说话(Talk only to your immediate friends and not to strangers)。其含义是:如果两个软件实体无须直接通信,那么就不应当发生直接的相互调用,可以通过第三方转发该调用。其目的是降低类之间的耦合度,提高模块的相对独立性。

    迪米特法则中的“朋友”是指:当前对象本身、当前对象的成员对象、当前对象所创建的对象、当前对象的方法参数等,这些对象同当前对象存在关联、聚合或组合关系,可以直接访问这些对象的方法。

    在应用迪米特法则时,一个对象只能与直接朋友发生交互,不要与“陌生人”发生直接交互,这样做可以降低系统的耦合度,一个对象的改变不会给太多其他对象带来影响。

    迪米特法则要求我们在设计系统时,应该尽量减少对象之间的交互,如果两个对象之间不必彼此直接通信,那么这两个对象就不应当发生任何直接的相互作用,如果其中的一个对象需要调用另一个对象的某一个方法的话,可以通过第三者转发这个调用。简言之,就是通过引入一个合理的第三者来降低现有对象之间的耦合度。

    在将迪米特法则运用到系统设计中时,要注意下面的几点:在类的划分上,应当尽量创建松耦合的类,类之间的耦合度越低,就越有利于复用,一个处在松耦合中的类一旦被修改,不会对关联的类造成太大波及;在类的结构设计上,每一个类都应当尽量降低其成员变量和成员函数的访问权限;在类的设计上,只要有可能,一个类型应当设计成不变类;在对其他类的引用上,一个对象对其他对象的引用应当降到最低。

    迪米特法则的优点

    迪米特法则要求限制软件实体之间通信的宽度和深度,正确使用迪米特法则将有以下两个优点。

    降低了类之间的耦合度,提高了模块的相对独立性。

    由于亲合度降低,从而提高了类的可复用率和系统的扩展性。

    但是,过度使用迪米特法则会使系统产生大量的中介类,从而增加系统的复杂性,使模块之间的通信效率降低。所以,在釆用迪米特法则时需要反复权衡,确保高内聚和低耦合的同时,保证系统的结构清晰

    迪米特法则的实现方法

    从迪米特法则的定义和特点可知,它强调以下两点:

    从依赖者的角度来说,只依赖应该依赖的对象。

    从被依赖者的角度说,只暴露应该暴露的方法。

    所以,在运用迪米特法则时要注意以下 6 点。

    在类的划分上,应该创建弱耦合的类。类与类之间的耦合越弱,就越有利于实现可复用的目标。

    在类的结构设计上,尽量降低类成员的访问权限。

    在类的设计上,优先考虑将一个类设置成不变类。

    在对其他类的引用上,将引用其他对象的次数降到最低。

    不暴露类的属性成员,而应该提供相应的访问器(set 和 get 方法)。

    谨慎使用序列化(Serializable)功能。

    下面通过一个简单实例来加深对迪米特法则的理解:

    Sunny软件公司所开发CRM系统包含很多业务操作窗口,在这些窗口中,某些界面控件之间存在复杂的交互关系,一个控件事件的触发将导致多个其他界面控件产生响应,例如,当一个按钮(Button)被单击时,对应的列表框(List)、组合框(ComboBox)、文本框(TextBox)、文本标签(Label)等都将发生改变,在初始设计方案中,界面控件之间的交互关系可简化为如图所示结构:

          在图中,由于界面控件之间的交互关系复杂,导致在该窗口中增加新的界面控件时需要修改与之交互的其他控件的源代码,系统扩展性较差,也不便于增加和删除新控件。

          现使用迪米特对其进行重构。

          在本实例中,可以通过引入一个专门用于控制界面控件交互的中间类(Mediator)来降低界面控件之间的耦合度。引入中间类之后,界面控件之间不再发生直接引用,而是将请求先转发给中间类,再由中间类来完成对其他控件的调用。当需要增加或删除新的控件时,只需修改中间类即可,无须修改新增控件或已有控件的源代码,重构后结构如图所示:

    总结

    单一职责原则告诉我们实现类要职责单一

    里氏替换原则告诉我们不要破坏继承体系

    依赖倒置原则告诉我们要面向接口编程

    接口隔离原则告诉我们在设计接口的时候要精简单一

    迪米特原则告诉我们要降低耦合

    开闭原则是总纲,告诉我们要对扩展开放,对修改关闭

    展开全文
  • 设计模式六大原则

    千次阅读 多人点赞 2018-09-06 14:38:04
    关于设计模式的六大设计原则的资料网上很多,但是很多地方解释地都太过于笼统化,我也找了很多资料来看,发现CSDN上有几篇关于设计模式六大原则讲述的比较通俗易懂,因此转载过来。  原作者博客链接:...

    关于设计模式的六大设计原则的资料网上很多,但是很多地方解释地都太过于笼统化,我也找了很多资料来看,发现CSDN上有几篇关于设计模式的六大原则讲述的比较通俗易懂,因此转载过来。

      原作者博客链接:http://blog.csdn.net/LoveLion/article/category/738450/7

    一.单一职责原则

      原文链接:http://blog.csdn.net/lovelion/article/details/7536542

      单一职责原则是最简单的面向对象设计原则,它用于控制类的粒度大小。单一职责原则定义如下:

    单一职责原则(Single Responsibility Principle, SRP):一个类只负责一个功能领域中的相应职责,或者可以定义为:就一个类而言,应该只有一个引起它变化的原因。

          单一职责原则告诉我们:一个类不能太“累”!在软件系统中,一个类(大到模块,小到方法)承担的职责越多,它被复用的可能性就越小,而且一个类承担的职责过多,就相当于将这些职责耦合在一起,当其中一个职责变化时,可能会影响其他职责的运作,因此要将这些职责进行分离,将不同的职责封装在不同的类中,即将不同的变化原因封装在不同的类中,如果多个职责总是同时发生改变则可将它们封装在同一类中。

          单一职责原则是实现高内聚、低耦合的指导方针,它是最简单但又最难运用的原则,需要设计人员发现类的不同职责并将其分离,而发现类的多重职责需要设计人员具有较强的分析设计能力和相关实践经验。

          下面通过一个简单实例来进一步分析单一职责原则:

    Sunny软件公司开发人员针对某CRM(Customer Relationship  Management,客户关系管理)系统中客户信息图形统计模块提出了如图1所示初始设计方案:

    图1  初始设计方案结构图

    在图1中,CustomerDataChart类中的方法说明如下:getConnection()方法用于连接数据库,findCustomers()用于查询所有的客户信息,createChart()用于创建图表,displayChart()用于显示图表。

    现使用单一职责原则对其进行重构。

          在图1中,CustomerDataChart类承担了太多的职责,既包含与数据库相关的方法,又包含与图表生成和显示相关的方法。如果在其他类中也需要连接数据库或者使用findCustomers()方法查询客户信息,则难以实现代码的重用。无论是修改数据库连接方式还是修改图表显示方式都需要修改该类,它不止一个引起它变化的原因,违背了单一职责原则。因此需要对该类进行拆分,使其满足单一职责原则,类CustomerDataChart可拆分为如下三个类:

          (1) DBUtil:负责连接数据库,包含数据库连接方法getConnection();

          (2) CustomerDAO:负责操作数据库中的Customer表,包含对Customer表的增删改查等方法,如findCustomers();

          (3) CustomerDataChart:负责图表的生成和显示,包含方法createChart()和displayChart()。

          使用单一职责原则重构后的结构如图2所示:

    图2  重构后的结构图

    二.开闭原则

      原文链接:http://blog.csdn.net/lovelion/article/details/7537584

      开闭原则是面向对象的可复用设计的第一块基石,它是最重要的面向对象设计原则。开闭原则由Bertrand  Meyer于1988年提出,其定义如下:

    开闭原则(Open-Closed Principle, OCP):一个软件实体应当对扩展开放,对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展。

          在开闭原则的定义中,软件实体可以指一个软件模块、一个由多个类组成的局部结构或一个独立的类

          任何软件都需要面临一个很重要的问题,即它们的需求会随时间的推移而发生变化。当软件系统需要面对新的需求时,我们应该尽量保证系统的设计框架是稳定的。如果一个软件设计符合开闭原则,那么可以非常方便地对系统进行扩展,而且在扩展时无须修改现有代码,使得软件系统在拥有适应性和灵活性的同时具备较好的稳定性和延续性。随着软件规模越来越大,软件寿命越来越长,软件维护成本越来越高,设计满足开闭原则的软件系统也变得越来越重要。

          为了满足开闭原则,需要对系统进行抽象化设计,抽象化是开闭原则的关键。在Java、C#等编程语言中,可以为系统定义一个相对稳定的抽象层,而将不同的实现行为移至具体的实现层中完成。在很多面向对象编程语言中都提供了接口、抽象类等机制,可以通过它们定义系统的抽象层,再通过具体类来进行扩展。如果需要修改系统的行为,无须对抽象层进行任何改动,只需要增加新的具体类来实现新的业务功能即可,实现在不修改已有代码的基础上扩展系统的功能,达到开闭原则的要求。

          Sunny软件公司开发的CRM系统可以显示各种类型的图表,如饼状图和柱状图等,为了支持多种图表显示方式,原始设计方案如图1所示:

    图1 初始设计方案结构图

          在ChartDisplay类的display()方法中存在如下代码片段:

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    ......

    if (type.equals("pie")) {

        PieChart chart = new PieChart();

        chart.display();

    }

    else if (type.equals("bar")) {

        BarChart chart = new BarChart();

        chart.display();

    }

    ......


          在该代码中,如果需要增加一个新的图表类,如折线图LineChart,则需要修改ChartDisplay类的display()方法的源代码,增加新的判断逻辑,违反了开闭原则。

          现对该系统进行重构,使之符合开闭原则。

           在本实例中,由于在ChartDisplay类的display()方法中针对每一个图表类编程,因此增加新的图表类不得不修改源代码。可以通过抽象化的方式对系统进行重构,使之增加新的图表类时无须修改源代码,满足开闭原则。具体做法如下:

          (1) 增加一个抽象图表类AbstractChart,将各种具体图表类作为其子类;

          (2)  ChartDisplay类针对抽象图表类进行编程,由客户端来决定使用哪种具体图表。

          重构后结构如图2所示:

    图2 重构后的结构图

          在图2中,我们引入了抽象图表类AbstractChart,且ChartDisplay针对抽象图表类进行编程,并通过setChart()方法由客户端来设置实例化的具体图表对象,在ChartDisplay的display()方法中调用chart对象的display()方法显示图表。如果需要增加一种新的图表,如折线图LineChart,只需要将LineChart也作为AbstractChart的子类,在客户端向ChartDisplay中注入一个LineChart对象即可,无须修改现有类库的源代码。    

           注意:因为xml和properties等格式的配置文件是纯文本文件,可以直接通过VI编辑器或记事本进行编辑,且无须编译,因此在软件开发中,一般不把对配置文件的修改认为是对系统源代码的修改。如果一个系统在扩展时只涉及到修改配置文件,而原有的Java代码或C#代码没有做任何修改,该系统即可认为是一个符合开闭原则的系统。

    三.里氏替换原则

      原文链接:http://blog.csdn.net/lovelion/article/details/7540445

      里氏代换原则由2008年图灵奖得主、美国第一位计算机科学女博士Barbara Liskov教授和卡内基·梅隆大学Jeannette Wing教授于1994年提出。其严格表述如下:如果对每一个类型为S的对象o1,都有类型为T的对象o2,使得以T定义的所有程序P在所有的对象o1代换o2时,程序P的行为没有变化,那么类型S是类型T的子类型。这个定义比较拗口且难以理解,因此我们一般使用它的另一个通俗版定义:

    里氏代换原则(Liskov Substitution Principle, LSP):所有引用基类(父类)的地方必须能透明地使用其子类的对象。

          里氏代换原则告诉我们,在软件中将一个基类对象替换成它的子类对象,程序将不会产生任何错误和异常,反过来则不成立,如果一个软件实体使用的是一个子类对象的话,那么它不一定能够使用基类对象。例如:我喜欢动物,那我一定喜欢狗,因为狗是动物的子类;但是我喜欢狗,不能据此断定我喜欢动物,因为我并不喜欢老鼠,虽然它也是动物。

          例如有两个类,一个类为BaseClass,另一个是SubClass类,并且SubClass类是BaseClass类的子类,那么一个方法如果可以接受一个BaseClass类型的基类对象base的话,如:method1(base),那么它必然可以接受一个BaseClass类型的子类对象sub,method1(sub)能够正常运行。反过来的代换不成立,如一个方法method2接受BaseClass类型的子类对象sub为参数:method2(sub),那么一般而言不可以有method2(base),除非是重载方法。

          里氏代换原则是实现开闭原则的重要方式之一,由于使用基类对象的地方都可以使用子类对象,因此在程序中尽量使用基类类型来对对象进行定义,而在运行时再确定其子类类型,用子类对象来替换父类对象

          在使用里氏代换原则时需要注意如下几个问题:

          (1)子类的所有方法必须在父类中声明,或子类必须实现父类中声明的所有方法。根据里氏代换原则,为了保证系统的扩展性,在程序中通常使用父类来进行定义,如果一个方法只存在子类中,在父类中不提供相应的声明,则无法在以父类定义的对象中使用该方法。

          (2) 我们在运用里氏代换原则时,尽量把父类设计为抽象类或者接口,让子类继承父类或实现父接口,并实现在父类中声明的方法,运行时,子类实例替换父类实例,我们可以很方便地扩展系统的功能,同时无须修改原有子类的代码,增加新的功能可以通过增加一个新的子类来实现。里氏代换原则是开闭原则的具体实现手段之一。

          (3) Java语言中,在编译阶段,Java编译器会检查一个程序是否符合里氏代换原则,这是一个与实现无关的、纯语法意义上的检查,但Java编译器的检查是有局限的。

          在Sunny软件公司开发的CRM系统中,客户(Customer)可以分为VIP客户(VIPCustomer)和普通客户(CommonCustomer)两类,系统需要提供一个发送Email的功能,原始设计方案如图1所示:

    图1原始结构图

          在对系统进行进一步分析后发现,无论是普通客户还是VIP客户,发送邮件的过程都是相同的,也就是说两个send()方法中的代码重复,而且在本系统中还将增加新类型的客户。为了让系统具有更好的扩展性,同时减少代码重复,使用里氏代换原则对其进行重构。

          在本实例中,可以考虑增加一个新的抽象客户类Customer,而将CommonCustomer和VIPCustomer类作为其子类,邮件发送类EmailSender类针对抽象客户类Customer编程,根据里氏代换原则,能够接受基类对象的地方必然能够接受子类对象,因此将EmailSender中的send()方法的参数类型改为Customer,如果需要增加新类型的客户,只需将其作为Customer类的子类即可。重构后的结构如图2所示:

    图2  重构后的结构图

          里氏代换原则是实现开闭原则的重要方式之一。在本实例中,在传递参数时使用基类对象,除此以外,在定义成员变量、定义局部变量、确定方法返回类型时都可使用里氏代换原则。针对基类编程,在程序运行时再确定具体子类。

      另外补充一篇关于里氏替换原则的一篇博文:

      http://blog.csdn.net/zhengzhb/article/details/7281833

    四.依赖倒置原则

      原文链接:http://blog.csdn.net/lovelion/article/details/7562783

      如果说开闭原则是面向对象设计的目标的话,那么依赖倒转原则就是面向对象设计的主要实现机制之一,它是系统抽象化的具体实现。依赖倒转原则是Robert C. Martin在1996年为“C++Reporter”所写的专栏Engineering Notebook的第三篇,后来加入到他在2002年出版的经典著作“Agile Software Development, Principles, Patterns, and Practices”一书中。依赖倒转原则定义如下:

    依赖倒转原则(Dependency Inversion  Principle, DIP):抽象不应该依赖于细节,细节应当依赖于抽象。换言之,要针对接口编程,而不是针对实现编程。

          依赖倒转原则要求我们在程序代码中传递参数时或在关联关系中,尽量引用层次高的抽象层类,即使用接口和抽象类进行变量类型声明、参数类型声明、方法返回类型声明,以及数据类型的转换等,而不要用具体类来做这些事情。为了确保该原则的应用,一个具体类应当只实现接口或抽象类中声明过的方法,而不要给出多余的方法,否则将无法调用到在子类中增加的新方法。

          在引入抽象层后,系统将具有很好的灵活性,在程序中尽量使用抽象层进行编程,而将具体类写在配置文件中,这样一来,如果系统行为发生变化,只需要对抽象层进行扩展,并修改配置文件,而无须修改原有系统的源代码,在不修改的情况下来扩展系统的功能,满足开闭原则的要求。

          在实现依赖倒转原则时,我们需要针对抽象层编程,而将具体类的对象通过依赖注入(DependencyInjection, DI)的方式注入到其他对象中,依赖注入是指当一个对象要与其他对象发生依赖关系时,通过抽象来注入所依赖的对象。常用的注入方式有三种,分别是:构造注入,设值注入(Setter注入)和接口注入。构造注入是指通过构造函数来传入具体类的对象,设值注入是指通过Setter方法来传入具体类的对象,而接口注入是指通过在接口中声明的业务方法来传入具体类的对象。这些方法在定义时使用的是抽象类型,在运行时再传入具体类型的对象,由子类对象来覆盖父类对象。

          下面通过一个简单实例来加深对依赖倒转原则的理解:

          Sunny软件公司开发人员在开发某CRM系统时发现:该系统经常需要将存储在TXT或Excel文件中的客户信息转存到数据库中,因此需要进行数据格式转换。在客户数据操作类中将调用数据格式转换类的方法实现格式转换和数据库插入操作,初始设计方案结构如图1所示:

    图1 初始设计方案结构图

          在编码实现图1所示结构时,Sunny软件公司开发人员发现该设计方案存在一个非常严重的问题,由于每次转换数据时数据来源不一定相同,因此需要更换数据转换类,如有时候需要将TXTDataConvertor改为ExcelDataConvertor,此时,需要修改CustomerDAO的源代码,而且在引入并使用新的数据转换类时也不得不修改CustomerDAO的源代码,系统扩展性较差,违反了开闭原则,现需要对该方案进行重构。

          在本实例中,由于CustomerDAO针对具体数据转换类编程,因此在增加新的数据转换类或者更换数据转换类时都不得不修改CustomerDAO的源代码。我们可以通过引入抽象数据转换类解决该问题,在引入抽象数据转换类DataConvertor之后,CustomerDAO针对抽象类DataConvertor编程,而将具体数据转换类名存储在配置文件中,符合依赖倒转原则。根据里氏代换原则,程序运行时,具体数据转换类对象将替换DataConvertor类型的对象,程序不会出现任何问题。更换具体数据转换类时无须修改源代码,只需要修改配置文件;如果需要增加新的具体数据转换类,只要将新增数据转换类作为DataConvertor的子类并修改配置文件即可,原有代码无须做任何修改,满足开闭原则。重构后的结构如图2所示:

    图2重构后的结构图

        

          在上述重构过程中,我们使用了开闭原则、里氏代换原则和依赖倒转原则,在大多数情况下,这三个设计原则会同时出现,开闭原则是目标,里氏代换原则是基础,依赖倒转原则是手段,它们相辅相成,相互补充,目标一致,只是分析问题时所站角度不同而已。

    五.接口隔离原则

      原文链接:http://blog.csdn.net/lovelion/article/details/7562842

      接口隔离原则定义如下:

    接口隔离原则(Interface  Segregation Principle, ISP):使用多个专门的接口,而不使用单一的总接口,即客户端不应该依赖那些它不需要的接口。

          根据接口隔离原则,当一个接口太大时,我们需要将它分割成一些更细小的接口,使用该接口的客户端仅需知道与之相关的方法即可。每一个接口应该承担一种相对独立的角色,不干不该干的事,该干的事都要干。这里的“接口”往往有两种不同的含义:一种是指一个类型所具有的方法特征的集合,仅仅是一种逻辑上的抽象;另外一种是指某种语言具体的“接口”定义,有严格的定义和结构,比如Java语言中的interface。对于这两种不同的含义,ISP的表达方式以及含义都有所不同:

          (1) 当把“接口”理解成一个类型所提供的所有方法特征的集合的时候,这就是一种逻辑上的概念,接口的划分将直接带来类型的划分。可以把接口理解成角色,一个接口只能代表一个角色,每个角色都有它特定的一个接口,此时,这个原则可以叫做“角色隔离原则”。

          (2) 如果把“接口”理解成狭义的特定语言的接口,那么ISP表达的意思是指接口仅仅提供客户端需要的行为,客户端不需要的行为则隐藏起来,应当为客户端提供尽可能小的单独的接口,而不要提供大的总接口。在面向对象编程语言中,实现一个接口就需要实现该接口中定义的所有方法,因此大的总接口使用起来不一定很方便,为了使接口的职责单一,需要将大接口中的方法根据其职责不同分别放在不同的小接口中,以确保每个接口使用起来都较为方便,并都承担某一单一角色。接口应该尽量细化,同时接口中的方法应该尽量少,每个接口中只包含一个客户端(如子模块或业务逻辑类)所需的方法即可,这种机制也称为“定制服务”,即为不同的客户端提供宽窄不同的接口。

          下面通过一个简单实例来加深对接口隔离原则的理解:

          Sunny软件公司开发人员针对某CRM系统的客户数据显示模块设计了如图1所示接口,其中方法dataRead()用于从文件中读取数据,方法transformToXML()用于将数据转换成XML格式,方法createChart()用于创建图表,方法displayChart()用于显示图表,方法createReport()用于创建文字报表,方法displayReport()用于显示文字报表。

    图1 初始设计方案结构图

          在实际使用过程中发现该接口很不灵活,例如如果一个具体的数据显示类无须进行数据转换(源文件本身就是XML格式),但由于实现了该接口,将不得不实现其中声明的transformToXML()方法(至少需要提供一个空实现);如果需要创建和显示图表,除了需实现与图表相关的方法外,还需要实现创建和显示文字报表的方法,否则程序编译时将报错。

          现使用接口隔离原则对其进行重构。

          在图1中,由于在接口CustomerDataDisplay中定义了太多方法,即该接口承担了太多职责,一方面导致该接口的实现类很庞大,在不同的实现类中都不得不实现接口中定义的所有方法,灵活性较差,如果出现大量的空方法,将导致系统中产生大量的无用代码,影响代码质量;另一方面由于客户端针对大接口编程,将在一定程序上破坏程序的封装性,客户端看到了不应该看到的方法,没有为客户端定制接口。因此需要将该接口按照接口隔离原则和单一职责原则进行重构,将其中的一些方法封装在不同的小接口中,确保每一个接口使用起来都较为方便,并都承担某一单一角色,每个接口中只包含一个客户端(如模块或类)所需的方法即可。

          通过使用接口隔离原则,本实例重构后的结构如图2所示:

    图2 重构后的结构图

         在使用接口隔离原则时,我们需要注意控制接口的粒度,接口不能太小,如果太小会导致系统中接口泛滥,不利于维护;接口也不能太大,太大的接口将违背接口隔离原则,灵活性较差,使用起来很不方便。一般而言,接口中仅包含为某一类用户定制的方法即可,不应该强迫客户依赖于那些它们不用的方法。

    六.迪米特法则

      原文链接:http://blog.csdn.net/lovelion/article/details/7563445

      迪米特法则来自于1987年美国东北大学(Northeastern University)一个名为“Demeter”的研究项目。迪米特法则又称为最少知识原则(LeastKnowledge Principle, LKP),其定义如下:

    迪米特法则(Law of  Demeter, LoD):一个软件实体应当尽可能少地与其他实体发生相互作用。

          如果一个系统符合迪米特法则,那么当其中某一个模块发生修改时,就会尽量少地影响其他模块,扩展会相对容易,这是对软件实体之间通信的限制,迪米特法则要求限制软件实体之间通信的宽度和深度。迪米特法则可降低系统的耦合度,使类与类之间保持松散的耦合关系。

          迪米特法则还有几种定义形式,包括不要和“陌生人”说话只与你的直接朋友通信等,在迪米特法则中,对于一个对象,其朋友包括以下几类:

          (1) 当前对象本身(this);

         (2) 以参数形式传入到当前对象方法中的对象;

          (3) 当前对象的成员对象;

          (4) 如果当前对象的成员对象是一个集合,那么集合中的元素也都是朋友;

          (5) 当前对象所创建的对象。

          任何一个对象,如果满足上面的条件之一,就是当前对象的“朋友”,否则就是“陌生人”。在应用迪米特法则时,一个对象只能与直接朋友发生交互,不要与“陌生人”发生直接交互,这样做可以降低系统的耦合度,一个对象的改变不会给太多其他对象带来影响。

          迪米特法则要求我们在设计系统时,应该尽量减少对象之间的交互,如果两个对象之间不必彼此直接通信,那么这两个对象就不应当发生任何直接的相互作用,如果其中的一个对象需要调用另一个对象的某一个方法的话,可以通过第三者转发这个调用。简言之,就是通过引入一个合理的第三者来降低现有对象之间的耦合度

          在将迪米特法则运用到系统设计中时,要注意下面的几点:在类的划分上,应当尽量创建松耦合的类,类之间的耦合度越低,就越有利于复用,一个处在松耦合中的类一旦被修改,不会对关联的类造成太大波及在类的结构设计上,每一个类都应当尽量降低其成员变量和成员函数的访问权限在类的设计上,只要有可能,一个类型应当设计成不变类在对其他类的引用上,一个对象对其他对象的引用应当降到最低

          下面通过一个简单实例来加深对迪米特法则的理解:

          Sunny软件公司所开发CRM系统包含很多业务操作窗口,在这些窗口中,某些界面控件之间存在复杂的交互关系,一个控件事件的触发将导致多个其他界面控件产生响应,例如,当一个按钮(Button)被单击时,对应的列表框(List)、组合框(ComboBox)、文本框(TextBox)、文本标签(Label)等都将发生改变,在初始设计方案中,界面控件之间的交互关系可简化为如图1所示结构:

    图1 初始设计方案结构图

          在图1中,由于界面控件之间的交互关系复杂,导致在该窗口中增加新的界面控件时需要修改与之交互的其他控件的源代码,系统扩展性较差,也不便于增加和删除新控件。

          现使用迪米特对其进行重构。

          在本实例中,可以通过引入一个专门用于控制界面控件交互的中间类(Mediator)来降低界面控件之间的耦合度。引入中间类之后,界面控件之间不再发生直接引用,而是将请求先转发给中间类,再由中间类来完成对其他控件的调用。当需要增加或删除新的控件时,只需修改中间类即可,无须修改新增控件或已有控件的源代码,重构后结构如图2所示:

    图2  重构后的结构图

    展开全文
  • GOF是设计模式的经典名著Design Patterns: Elements of Reusable Object-Oriented Software(中译本名为《设计模式——可复用面向...他们总结了23个设置模式,以下将给出这23个设计模式的说明,及设计模式六大原则.
  • 设计模式六大基本原则

    千次阅读 2017-07-21 22:36:43
    1.开闭原则:开闭原则就是说对扩展...2.里氏替换原则:里氏替换原则是面向对象设计的基本原则之一。里氏替换原则说,任何基类出现的地方,子类一定可以出现。LSP是继承复用的基石,只有当衍生类可以替换掉基类,软件

    1.开闭原则:开闭原则就是说对扩展开放,对修改关闭,在程序需要进行扩展的时候,不能去修改原有代码,实现一个热插拔的效果。所以一句话概括就是:为了使程序的扩展性好,易于维护和升级。想要达到这样的效果,我们需要使用接口和抽象类。

    2.里氏替换原则:里氏替换原则是面向对象设计的基本原则之一。里氏替换原则说,任何基类出现的地方,子类一定可以出现。LSP是继承复用的基石,只有当衍生类可以替换掉基类,软件单位的功能不受影响时,基类才能真正被复用,而衍生类也能够在基类的基础上增加新的行为。里氏替换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤是抽象化的具体实现,所以里氏替换原则是对应实现抽象化的具体步骤的规范。

    3.依赖倒转原则:这个是开闭原则的基础,具体内容:直接接口编程(如集成sdk),依赖抽象而不依赖具体。

    4.接口隔离原则:这个原则的意思是:使用多个隔离的接口,比使用单个接口要好。这是一个降低类之间耦合度的意思,从我们这儿可以看出,其实设计模式就是一个软件的设计思想,从大型软件架构出发,为了升级和维护方便。所以上文中多次出现:降低依赖,降低耦合。

    5.迪米特原则(最少知道原则)就是说一个实例应当尽量少的与其他实体之间发生相互作用,使得系统模块相对独立。

    6.合成复用原则:原则是尽量使用合成/聚成,而不是使用继承。

    展开全文
  • 设计模式6大原则.zip

    2019-09-10 16:36:02
    设计模式六大原则的一点总结,欢迎免费下载。
  • 二、设计模式六大原则 1、开闭原则(Open Close Principle) 开闭原则就是说对扩展开放,对修改关闭。在程序需要进行拓展的时候,不能去修改原有的代码,实现一个热插拔的效果。所以一句话概括就是:为了使程序...
  • 软件设计六大原则

    千次阅读 2019-03-10 14:56:02
    一、单一职责原则(SRP: Single responsibility principle) 二、开放封闭原则(OCP: Open Closed Principle) 三、里氏替换原则 ( LSP: Liskov Substitution Principle) 四、接口隔离原则( ISP: Interface ...
  • 软件设计模式(Design pattern),又称设计模式,是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性、程序的重用性。...
  • 分别就是Java设计模式六大原则和常用的23种设计模式了。本篇是对六大原则的整理。(最后一种是哈姆雷特)1.开闭原则(Open Close Principle)定义:一个软件实体如类、模块和函数应该对扩展开放,对修改关闭。 开放-...
  • 补充一下面对对象设计八大原则:前五大原则设计模式的前五大原则相同,为: 1、单一职责原则(Single Responsibility Principle, SRP):一个类只负责一个功能领域中的相应职责,或者可以定义为:就一个类而言,...
  • Unity3d程序必备设计模式六大原则

    千次阅读 2016-06-29 07:35:41
    Unity3d程序必备设计模式六大原则 Unity编程众所周知,它是属于脚本化,脚本没有一个具体的概念跟架构,导致在项目过程中,经常出现哪里需要实现什么功能,就随便添加脚本,结果,就造成了一片混乱,不好管理。更有...
  • 里氏替换原则 开闭原则 依赖倒置原则 接口分离原则 迪米特法则 记忆方法: 一个单身(单一职责)的里氏(里氏替换原则)拿着一把颠倒(依赖倒置)的半开半闭(开闭原则)的扇子,在看接口分离(接口分离)问题,...
  • 设计模式分类以及六大设计原则(汇总篇)

    万次阅读 多人点赞 2018-05-22 22:36:28
    设计模式的分类 创建型模式,共五种: 单例模式、工厂方法模式、抽象工厂模式、建造者模式、原型模式。 结构型模式,共七种: 适配器模式、装饰者模式、代理模式、门面模式(外观模式)、桥梁模式、组合模式、享...
  • 大话设计模式——六大原则(SOLID)

    千次阅读 2017-08-05 21:06:08
    软件系统中,一个类(到模块,小到方法)承担的职责越多,它被复用的可能性就越小,而且一个类承担的职责过多,就相当于将这些职责耦合在一起,当其中一个职责变化时,可能会影响其他职责的运作,因此要将这些...
  • Java设计模式六大原则

    千次阅读 2018-03-20 13:59:09
    一.单一职责原则 单一职责原则是最简单的面向对象设计原则,它用于控制类的粒度大小。单一职责原则定义如下:单一职责原则(Single Responsibility ...在软件系统中,一个类(到模块,小到方法)承担的职责...
  • 设计模式六大原则——SOLID

    万次阅读 多人点赞 2018-08-12 20:34:32
    设计模式六大原则有: Single Responsibility Principle:单一职责原则 Open Closed Principle:开闭原则 Liskov Substitution Principle:里氏替换原则 Law of Demeter:迪米特法则 Interface Segregation ...
  • 软件工程六大设计原则

    千次阅读 2020-01-07 16:57:43
    1、单一职责原则 概念描述 对类来说,一个类应该只负责一项职责。如果一个类负责两个职责,可能存在职责1变化,引起职责2的变化情况。可以基于抽象逻辑,或者业务逻辑对类进行细化。 2、接口隔离原则 概念描述...
  • 【JAVA设计模式】设计六大原则

    千次阅读 多人点赞 2018-12-28 09:02:18
    - 单一职责原则(SRP) 定义:就一个类而言,应该仅有一个引起它变化的原因。 从这句定义我们很难理解它的含义,通俗讲就是我们不要让一个类承担过多的职责。如果一个类承担的职责过多,就等于把这些职责耦合在一起...
  • 设计模式的三大分类及六大原则

    万次阅读 多人点赞 2018-08-20 00:47:11
    总体来说设计模式分为三类: 创建型模式,共五种:工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。 结构型模式,共七种:适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元...
  • 设计模式六大原则(6):开闭原则

    万次阅读 多人点赞 2012-02-27 08:48:41
    定义:一个软件实体如类、模块和函数应该对扩展开放,对修改关闭。 问题由来:在软件的生命周期内,因为变化、升级和维护等原因需要对软件原有代码进行修改时,可能会给旧代码中引入错误,... 开闭原则是面向对象设计
  • PHP设计模式——六大原则

    千次阅读 2015-04-06 23:18:54
    声明:本系列博客参考资料《大话设计模式》,作者程杰...这六大原则任何面向对象的语言都应该遵守的,要想让你的代码易扩展高服用就尽量去满足这六大原则吧,不一定严格按照某种设计模式,但是如果你的代码符合这六大原
  • 设计模式六大基本原则

    千次阅读 2018-07-05 11:27:10
    面向对象的设计,我们通常会涉及到两个元素:接口,类,及他们之间的协作关系。...对于有继承关系的类设计,要注意子类是否改变父类的方法,目标是不要改变,子类应该只扩展父类的行为(里氏替换原则,开闭原则)...
  • 之前我们对设计模式六大原则做了简单归纳,这篇博客是对开放封闭原则进行的举例说明。 开放封闭原则的意义软件实体应该对扩展开放,对修改关闭,其含义是说一个软件实体应该通过扩展来实现变化,而不是通过修改已...
  • 软件架构设计六大原则

    万次阅读 多人点赞 2017-07-26 09:50:28
    1. 单一职责原则(Single Responsibility Principle - SRP) 原文:There should never be more than one reason for a class to change. 译文:永远不应该有多于一个原因来改变某个类。 理解:对于一个类而言...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 48,439
精华内容 19,375
关键字:

软件设计模式六大原则