设计模式之设计模式六大原则（三大基本原则）【1】

　　随着软件项目的经验增加与深入，逐渐感觉到软件在代码上的冗余不断提高与可维护性的降低，亟待软件设计思想来指导我们的代码，如何变得更加优美动人，使得软件更加具有可维护性，可复用性，可拓展性，并达到软件的高内聚低耦合目标。恰好的是，软件设计模式，就是这样一部经典的指导思想。以下，将展开对设计模式的六大原则（开闭原则、里氏代换原则、依赖倒转原则、单一职责原则、接口隔离原则、迪米特法则）的解析。

一、开闭原则（Open-Closed-Principle）

 　　核心：一个软件实体应当对拓展开放，对修改关闭。即：软件实体应尽量在不修改原有代码的情况下进行拓展。

　　

　　对Operation类的修改关闭，对Operation类的继承（拓展）开放。

二、里氏代换原则（Liskow-Substitution-Principle）

 　　核心：所有引用基类（父类）的地方，都必须能透明地使用其子类的对象。

　　1.一个软件实体如果使用的是一个父类，那么一定适用于其子类，而且他察觉不出父类对象和子类对象的区别。也就是说，在软件里面，吧父类都替换成它的子类，程序的行为没有变化。简单地说，子类新必须能够替换掉它们的父类型。

　　  Eg1：

　　　　我喜欢动物（父类）------（替换为）------->我喜欢狗（子类）      【√】

　　　我喜欢狗（子类）   ------（替换为）------->我喜欢动物（父类）   【×】　　

　

Eg2：

Animal  animal  =  new Cat();

animal.eat();

animal.drink();

animal.run();

animel.shut();

　　　　注:需求的变化，使得需要将Cat更换为Dog，Snake，Sheep等别的动物，程序其他地方不需要改变。

Eg3:

class PersonUser{

        usePerson(Person person){ ...;person.say(); }

}


abstract class Person{

        abstract public void say();

}  


class Male extends Person{

        @override
        public void say(){
   
             System.out.println("I am a Male.");
        }

}


class Female extends Person{

        @override
        public void say(){
   
             System.out.println("I am a Female.");
        }

}

========================

Client:

　　　　PersonUser personUser = new PersonUser();

　　　　personUser.usePerson(new Male);

　　　　personUser.usePerson(new Female); 
         
========================
Output:
            I am Male.
            I am Female.

　　2.父类：抽象类/接口；子类：实现类

　　  　　

　　

三、依赖倒转原则（Dependency-Inversion-Principle）

 　　核心：抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对接口编程，而非针对实现编程。

 　　思想：抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。依赖倒转其实可以说是面向对象设计的标志，用哪种语言来编写程序不重要，如果编写时考虑的都是如何针对抽象编程而不是针对细节编程，即 程序中所有的依赖关系都是终止于抽象类或者接口，那就是面向对象的设计，反之就是面向过程化设计了。

　　原则：依赖倒转原则：

　　　　　　1.高层模块不应该依赖于低层模块。两个都应该依赖于抽象。

　　　　　　2.抽象不应该依赖细节。细节应该依赖于抽象。 

 

 　　

　　问题由来：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。
　　解决方案：将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类B或者类C发生联系，则会大大降低修改类A的几率。
依赖倒置原则基于这样一个事实：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。在java中，抽象指的是接口或者抽象类，细节就是具体的实现类，使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。

　　经典解说链接：【 设计模式六大原则（3）：依赖倒置原则】

　　【防止目标网页丢失，备份如下：】

　　场景：

　　(1)场景是这样的，母亲给孩子讲故事，只要给她一本书，她就可以照着书给孩子讲故事了。　

class Book{  
    public String getContent(){  
        return "很久很久以前有一个阿拉伯的故事……";  
    }  
}  
  
class Mother{  
    public void narrate(Book book){  
        System.out.println("妈妈开始讲故事");  
        System.out.println(book.getContent());  
    }  
}  
  
public class Client{  
    public static void main(String[] args){  
        Mother mother = new Mother();  
        mother.narrate(new Book());  
    }  
}  

===========================================
output:
　　妈妈开始讲故事
　　很久很久以前有一个阿拉伯的故事……

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

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());  
    }  
}  

===========================================
output：
　　妈妈开始讲故事
　　很久很久以前有一个阿拉伯的故事……
　　妈妈开始讲故事
　　林书豪17+9助尼克斯击败老鹰……

【依赖倒转小结】

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

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

       传递依赖关系有三种方式，以上的例子中使用的方法是接口传递，另外还有两种传递方式：构造方法传递和setter方法传递，相信用过Spring框架的，对依赖的传递方式一定不会陌生。
在实际编程中，我们一般需要做到如下3点：

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

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

　　

　　小结：开闭原则是目标，里氏代换是基础，依赖倒转是手段。

四、单一职责原则（Single-Responsibility-Principle）

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

 　　思想：如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。【Eg:游戏的界面组成与逻辑组成分离】

　　

五、接口隔离原则（Interface-Segregation-Principle）

 　　核心：使用多个专门的接口，而不使用单一的总接口。即 客户端不应该依赖于那些它不需要的接口。

六、迪米特法则（Law-Of-Demeter）

　　核心：一个软件实体应当尽可能少地与其他实体发生作用。（无熟人难办事）

 　  思想：也叫最少知识原则。如果两个类不彼此通信，那么这两个类就不应当直接地发生相互作用。如果其中一个类需要另一个类的某一个方法的话，可以通过第三者转发这个调用。（不要和陌生人说话）

　　原则：

　　在迪米特法则中，对于一个对象，其朋友包括如下几类：

　　（1）当前对象 this

　　（2）以参数形式传入到当前对象方法中的对象

　　（3）当前对象的成员对象

　　（4）若当前对象的成员你对象是一个集合，那么集合中的对象也都是朋友

　　（5）当前对象所创建的对象

 　　

七、参考文献

　　[1] 迪米特原则( Law of Demeter)

　　[2] 设计模式六大原则 - 迪米特法则

八、推荐书目

　　[1]《大话设计模式》【通俗易懂】

　　[2]《HeadFirst设计模式》【经典著作】

　　[3]《设计模式：可复用面向对象软件的基础》