设计模式原则

1：单一职责原则（Single Responsibility Principle）
定义：一个对象应该只包含单一的职责，并且该职责被完整地封装在一个类中。
分析：
（1）一个类（或者大到模块，小到方法）承担的职责越多，它被复用的可能性越小。如果一个类承担不同的职责，就相当于将这些职责耦合在一起，当其中一个职责变化时，可能会影响到其他职责的运作。为了避免上述情况的发生，应建立不同的类对应不同的功能。
（2）类的职责主要包括两个方面：数据职责和行为职责，数据职责通过其属性来体现，而行为职责通过其方法来体现。
（3）说到单一职责原则，很多人都觉得它太简单了，但是即便是经验丰富的程序员写出的程序，也会有违背这一原则的代码存在。为什么会出现这种现象呢？因为有职责扩散。所谓职责扩散，就是因为某种原因，单一职责被分化为粒度更细的职责1和2。比如：类T只负责一个职责P，这样设计是符合单一职责原则的。后来由于某种原因，需要将职责P细分为粒度更细的职责P1和P2，这时如果要使程序遵循单一职责原则，需要将类T也分解为两个类T1和T2，分别负责P1、P2两个职责。但是在程序已经写好的情况下，这样做简直太费时间了。所以，简单的修改类T，用它来负责两个职责是一个比较不错的选择，虽然这样做有悖于单一职责原则。（这样做的风险在于职责扩散的不确定性，因为我们不会想到这个职责P，在未来可能会扩散为P1，P2，P3，P4……Pn。所以记住，在职责扩散到我们无法控制的程度之前，立刻对代码进行重构。）
（4）如何判断该类是否具有单一职责呢？如果有多于一个的动机去改变一个类，那么这个类就是有多于一个的职责。

2：里氏代换原则（Liskov Substitution Principle）
定义：所有引用基类的地方必须能透明地使用其子类的对象。
分析：
（1）讲的是基类和子类的关系，只有这种关系存在时，里氏代换原则才存在。
（2）里氏代换原则可以通俗表述为：在软件中如果能够使用基类对象，那么一定能够使用其子类对象。把基类都替换成它的子类，程序将不会产生任何错误和异常，反过来则不成立，如果一个软件实体使用的是一个子类的话，那么它不一定能够使用基类。
（3）里氏代换原则是实现开闭原则的重要方式之一，由于使用基类对象的地方都可以使用子类对象，因此在程序中尽量使用基类类型来对对象进行定义。
（4）继承作为面向对象三大特性之一，在给程序设计带来巨大便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低，增加了对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能会产生故障。
（5）当子类继承并且覆盖父类方法的时候，子类中的方法的可见性（访问限制）必须等于或者大于父类中的方法的可见性，子类中的方法所抛出的受检异常只能是父类中对应方法所抛出的受检异常的子类。

3：依赖倒置原则（Dependence Inversion Principle）
定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。
分析：
（1）高层模块和低层模块：每一个逻辑的实现都是由原子逻辑组成的，不可分割的原子逻辑就是低层模块，原子逻辑的再组装就是高层模块。
（2）相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。在Java语言中，抽象就是指接口或抽象类，两者都是不能直接被实例化的；细节就是实现类，实现接口或继承抽象类而产生的类就是细节，其特点就是可以直接被实例化。
（3）依赖倒置原则在Java语言中的表现就是：模块间的依赖是通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的；接口或抽象类不依赖于实现类；实现类依赖接口或抽象类。要针对接口编程，不针对实现编程。
（4）依赖倒置原则是面向对象设计的标志，它的核心思想是面向接口编程。
（5）传递依赖关系有三种方式：接口传递；构造方法传递和setter方法传递。
（6）依赖关系(Dependency)：是一种使用关系，特定事物的改变有可能会影响到使用该事物的其他事物，在需要表示一个事物使用另一个事物时使用依赖关系。（假设A类的变化引起了B类的变化，则说名B类依赖于A类。）大多数情况下，依赖关系体现在某个类的方法使用另一个类的对象作为参数。在UML中，依赖关系用带箭头的虚线表示，由依赖的一方指向被依赖的一方。

4：接口隔离原则（Interface Segregation Principle）
定义：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。
分析：
（1）接口隔离原则是指使用多个专门的接口，而不使用单一的总接口。每一个接口应该承担一种相对独立的角色，不多不少，不干不该干的事，该干的事都要干。
（2）使用接口隔离原则拆分接口时，首先必须满足单一职责原则，将一组相关的操作定义在一个接口中，且在满足高内聚的前提下，接口中的方法越少越好。
（3）类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类B来说不是最小接口，则类B和类D必须去实现他们不需要的方法。为避免上述情况的发生，将臃肿的接口I拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系。

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不是必需的，但是由于接口I中有这两个方法，
    //所以在实现过程中即使这两个方法的方法体为空，也要将这两个没有作用的方法进行实现。
    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不是必需的，但是由于接口I中有这两个方法，
    //所以在实现过程中即使这两个方法的方法体为空，也要将这两个没有作用的方法进行实现。
    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());
    }
}

（4）也许很多人会觉的接口隔离原则跟单一职责原则很相似，其实不然。其一，单一职责原则原注重的是职责；而接口隔离原则注重对接口依赖的隔离。其二，单一职责原则主要是约束类，其次才是接口和方法，它针对的是程序中的实现和细节；而接口隔离原则主要约束接口，主要针对抽象，针对程序整体框架的构建。
（5）运用接口隔离原则，一定要适度，接口设计的过大或过小都不好。如果过小，则会造成接口数量过多，使设计复杂化。所以一定要适度。

5：迪米特法则（Demeter Principle）
定义：如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。
分析：
（1）类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。因此，要尽量降低类与类之间的耦合。
（2）软件编程的总原则为低耦合，高内聚。无论是面向过程编程还是面向对象编程，只有使各个模块之间的耦合尽量的低，才能提高代码的复用率。低耦合的优点不言而喻，但是怎么样编程才能做到低耦合呢？那正是迪米特法则要去完成的。迪米特法则又叫最少知道原则，通俗的来讲，就是一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类来说，无论逻辑多么复杂，都尽量地的将逻辑封装在类的内部，对外除了提供的public方法，不对外泄漏任何信息。迪米特法则还有一个更简单的定义：只与直接的朋友通信。
（3）什么是朋友？
当前对象本身(this)；
以参数形式传入到当前对象方法中的对象；
当前对象的成员对象；
如果当前对象的成员对象是一个集合，那么集合中的元素也都是朋友；
当前对象所创建的对象。
任何一个对象，如果满足上面的条件之一，就是当前对象的“朋友”，否则就是“陌生人”。

6：合成/聚合原则（Composite Reuse Principle）
定义：尽量使用合成/聚合而不是继承来达到软件复用的目的。
分析：
（1）在面向对象设计中，可以通过两种基本方法在不同的环境中复用已有的设计和实现，即通过组合/聚合关系或通过继承。
继承复用：实现简单，易于扩展。破坏系统的封装性；从基类继承而来的实现是静态的，不可能在运行时发生改变，没有足够的灵活性；只能在有限的环境中使用。（“白箱”复用）
组合/聚合复用：耦合度相对较低，选择性地调用成员对象的操作；可以在运行时动态进行。（“黑箱”复用）
（2）组合/聚合可以使系统更加灵活，类与类之间的耦合度降低，一个类的变化对其他类造成的影响相对较少，因此一般首选使用组合/聚合来实现复用；其次才考虑继承，在使用继承时，需要严格遵循里氏代换原则，有效使用继承会有助于对问题的理解，降低复杂度，而滥用继承反而会增加系统构建和维护的难度以及系统的复杂度，因此需要慎重使用继承复用。
（3）此原则和里氏代换原则氏相辅相成的,两者都是具体实现”开-闭”原则的规范。违反这一原则，就无法实现”开-闭”原则，首先我们要明白合成和聚合的概念：
合成表示一种强的拥有关系，体现了严格的部分和整体的关系，部分和整体的生命周期一样，打个比方：人有两个胳膊，胳膊和人就是部分和整体的关系，人去世了，那么胳膊也就没用了，也就是说胳膊和人的生命周期是相同的。
聚合表示一种弱的拥有关系，体现的是A对象可以包含B对象，但是B对象并不是A对象的一部分，打个比方：人是群居动物，所以每个人属于一个人群，一个人群可以有多个人，所以人群和人是聚合的关系。

7：开放-封闭原则(Open close Principle)
定义：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。
分析：
（1）在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试。为了避免上述情况的发生，我们要尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。
（2）实现开闭原则的关键就是抽象化 :在”开-闭”原则中,不允许修改的是抽象的类或者接口,允许扩展的是具体的实现类,抽象类和接口在”开-闭”原则中扮演着极其重要的角色，既要预知可能变化的需求，又要预见所有可能已知的扩展，所以在这里”抽象化”是关键。
（3）可变性的封闭原则:找到系统的可变因素,将它封装起来. 这是对”开-闭”原则最好的实现. 不要把可变因素放在多个类中,或者散落在程序的各个角落。应该将可变的因素封套起来，并且切忌不要把所用的可变因素封套在一起。 最好的解决办法是,分块封套，避免超大类,超长类,超长方法的出现。
（4）开闭原则是面向对象设计中最基础的设计原则，它指导我们如何建立稳定灵活的系统。其实，设计模式其他5大原则的目的就是遵循开闭原则：单一职责原则告诉我们实现类要职责单一；里氏替换原则告诉我们不要破坏继承体系；依赖倒置原则告诉我们要面向接口编程；接口隔离原则告诉我们在设计接口的时候要精简单一；迪米特法则告诉我们要降低耦合。开闭原则就是总纲，它告诉我们要对扩展开放，对修改关闭。

转自：> http://blog.csdn.net/zhengzhb/article/category/926691/1
转自：> http://blog.csdn.net/liaoqianchuan00/article/category/1290660