设计模式简析与汇总

预计阅读时间：10 分钟

1、设计模式的种类

设计模式分为三大类：

• 创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。
• 结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。
• 行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。
• 其实还有两类：并发型模式和线程池模式。

2、面向对象的设计的原则

• 单一责任原则：让一个类只做一种类型责任，当这个类需要承当其他类型的责任的时候，就需要分解这个类。
• 开放封闭原则：对扩展是开放的，而对修改是封闭的。
• 里氏替换原则：当一个子类的实例应该能够替换任何其超类的实例时，它们之间才具有is-A关系
• 依赖倒置原则：高层模块不应该依赖于低层模块，二者都应该依赖于抽象；抽象不应该依赖于细节，细节应该依赖于抽象
• 接口分离原则：不能强迫用户去依赖那些他们不使用的接口。换句话说，使用多个专门的接口比使用单一的总接口总要好。
• 迪米特法则（最少知道原则）：一个类对自己依赖的类知道的越少越好。无论被依赖的类多么复杂，都应该将逻辑封装在方法的内部，通过public方法提供给外部。这样当被依赖的类变化时，才能最小的影响该类。
• 合成复用原则：尽量首先使用组合/聚合的方式，而不是使用继承。

3、设计原则简析

（1）单一职责原则（Single Responsibility Principle）
1）优点

• 类的复杂性降低，实现什么职责都有清晰明确的定义
• 可读性提高，复杂性降低
• 可维护性提高，变更引起的风险降低

2）扩展：单一职责原则适用于接口、类，同时也适用于方法，一个方法尽可能只做一件事，例如
坏的设计：一个方法承担多个职责
好的设计：一个方法承担一个职责

3）注意：设计时尽可能做到职责单一，但是对于实现类切勿生搬硬套该原则，可能会引起类的剧增，这个原则一般在项目中很难得到体现，在项目开发中常常需要考虑环境、工作量、技术水平、硬件资源等，最终得到一个妥协的结果

4）建议：接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化

（2）开放封闭原则（Open Closed Principle）
1）定义：一个软件实体，如类、模块和函数应该对扩展开放，对修改关闭
2）使用

• 抽象约束：通过接口或抽象类约束扩展，对扩展进行边界限定
• 封装变化：将相同的变化封装到一个接口或抽象类中，不应该有两个不同的变化出现在同一个接口或抽象类中

（3）里氏替换原则（Liskov Substitution Principle）
1）优点

• 代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性
• 提高代码的可扩展性

2）缺点

• 继承具有侵入性，只要继承，就必须拥有父类的所有属性和方法
• 降低代码的灵活性
• 增加了耦合性，当父类的常量、变量和方法被修改时，需要考虑子类的修改

3）特点

• Java使用extends关键字来实现继承，只能单一继承
• 覆盖或实现父类的方法时输入参数可以被放大，准确地说，子类中方法的入参必须比父类中被覆写

public class Father{
    public Collection doSomething(HashMap map){
        System.out.println("父类被执行");
        return map.values();
    }
}
public class Son extends Father{
    // 输入参数放大,注意不是覆写（Override）父类方法，虽然方法名相同，但输入参数不同
    public Collection doSomething(Map map){
        System.out.println("子类被执行");
        return map.values();
    }
}
public class Client{
    public static void invoker(){
        // 有父类的地方，就可以用子类
        // Father f = new Father();
        Son f = new Son();
        HashMap map = new HashMap();
        f.doSomething(map);
    }
    public static void main(String[] args){
        invoker();
    }
}

• 覆写或实现父类的方法时输出结果可以被缩小

4）定义：所有引用基类的地方必须能透明地使用其子类的对象，通俗的讲，只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用者根本不能觉察出时父类还是子类，注意反过来就不行了，有子类的地方，父类未必适应

5）建议：如果子类不能完整地实现父类的方法，或者父类的某些方法在子类中已经发生“畸变”，建议断开父子继承关系，采用依赖、聚集、组合等关系代替继承

（4）依赖倒置原则（Dependence Inversion Principle）

1）定义：

• 高层模块不应该依赖低层模块，两者都应该依赖其抽象
• 抽象不应该依赖细节
• 细节应该依赖抽象

总结：抽象指的就是接口或抽象类，两者都是不能被直接实例化的；细节就是实现类。模块间的依赖应该通过抽象产生，实现类之间不发生直接的依赖关系，实现类依赖接口或抽象类，反之不可。

2）优点：依赖倒置原则可以减少类间的耦合性，提高系统的稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性

3）建议：客户端代码属于高层业务逻辑，它对低层模块的依赖都建立在抽象上

（5）接口隔离原则（Interface Segregation Principle）
1）定义：类的依赖关系应该建立在最小的接口上，应当具有“接口尽量小”、“接口要高内聚”、“接口设计是有限度的”等特点，尽量保证接口的纯洁性

2）建议：

• 一个接口只服务于一个子模块或业务逻辑
• 通过业务逻辑压缩接口中的public方法，接口时常去回顾
• 已经被污染的接口，尽量去修改，若转化的风险较大，则采用适配器模式进行转化

（6）迪米特法则（Law of Demeter）
1）定义：一个对象应该对其他对象有最少的了解，对类的低耦合提出了明确的要求
2）建议：尽量不要对外公布太多的public方法和非静态的public变量，多使用private、protected等访问权限

（7）合成复用原则（Composite Reuse Principle）
1）定义：尽量使用对象组合/聚合, 而不是继承关系达到软件复用的目的，继承实际上破坏了类的封装性，超类的方法可能会被子类修改。

2）使用：通过将已有的对象纳入新对象中，作为新对象的成员对象来实现的，新对象可以调用已有对象的功能，从而达到复用。

3）建议：在软件复用时，要尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。如果要使用继承关系，则必须严格遵循里氏替换原则。合成复用原则同里氏替换原则相辅相成的，两者都是开闭原则的具体实现规范。

4、总结

设计原则是软件设计模式必须尽量遵循的原则，各种原则要求的侧重点不同。
1）开闭原则是总纲，它告诉我们要对扩展开放，对修改关闭；
2）里氏替换原则告诉我们不要破坏继承体系；
3）依赖倒置原则告诉我们要面向接口编程；
4）单一职责原则告诉我们实现类要职责单一；
5）接口隔离原则告诉我们在设计接口的时候要精简单一；
6）迪米特法则告诉我们要降低耦合度；
7）合成复用原则告诉我们要优先使用组合或者聚合关系复用，少用继承关系复用。

尾注

• 上述的总结与思考是基于对《设计模式之禅》这本书的精读与演绎
• 更多及时干货，请关注微信公众号：JAVA万维猿圈