乐趣区

设计模式小结

jiezi

设计原则

单一职责

一个类只应该负责一个功能，或者说只有一个原因可以导致这个类改变。

里氏替换

任何父类对象出现的地方都可以替换为子类，而且原程序不会产生任何异常。

并非满足父子关系的对象都满足上述条件，如下。这时子类替换父类，调用 doSomething(new HashMap()) 即不会走继承父类方法，也不会走子类重写的方法，而是会走到子类的重载方法中，也就是走到了一个和父类完全不相关的方法之中，这是意料之外的。

// 父类方法
public void doSomething(Map map);

// 子类重载方法
public void doSomething(HashMap map);

依赖倒置

  1. 高层次的模块不应该直接依赖低层次的模块，而应该通过两者的抽象进行依赖描述。
  2. 抽象不应该依赖具体实现
  3. 具体实现应该依赖抽象

接口隔离

用户不应该被迫依赖他们不需要的接口；类之间的关系应该建立在最小的接口上。

比如，在设计接口时，如果用户总是使用里面的部分方法，则应该拆成两个接口，分别向外提供功能。

迪米特法则（最少知识）

一个对象应该对自己耦合的对象知道的越少越好。满足这个条件一般要做到：

  1. 只和自己直接耦合的对象交流，而不应该出现 A ->B->C 导致 A ->C 直接耦合的情况。
  2. 被耦合的对象应该提供尽量少的方法给用户使用，用户对自己了解越少越好。

开闭原则

一个软件实体如类、模块和方法应该对扩展开放，对修改关闭。即，软件应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化。

设计模式核心思想

  1. 单例模式

    • 整个系统中，这个类只有一个对象，使用者只能使用该唯一的对象

  2. 工厂方法模式

    • 定义一个创建对象的方法，由子类去实现具体创建过程

  3. 抽象工厂模式

    • 定义一组工厂方法，这些方法会创建一个家族的组件。由子类决定创建什么家族的组件

  4. 模板方法

    • 用一个方法描述整个流程，该流程又分为多个步骤，每个步骤在抽象类中不实现，交由具体的子类去实现
    • 将处理过程的描述和分步骤的具体实现相分离，提高代码的灵活性

  5. 建造者模式

    • 一个对象由各个组件构成，而且像向该对象添加这些组件的顺序会影响最后构造的对象，则可以使用建造者模式

  6. 代理模式

    • 代理人和被代理人拥有相同的接口，在具体方法被调用时，代理人可以在执行前后做一些操作
    • 该模式可以使得被代理人专注的实现自己的功能，而将增强功能交给代理人来实现，整个过程对使用者是透明的

  7. 原型模式

    • 定义一个原型对象，通过克隆该原型的方式直接创建一个新对象，省去了构造对象的麻烦和性能损耗

  8. 中介者模式

    • 由一个中介对象负责各个组件之间的交互，而各个组件之间不直接耦合，构成一种星状结构
    • 目的是减少各个模块之间复杂的耦合

  9. 命令模式

    • 将调用者和被调用者之间的请求变为一个对象，从而方便的记录、回滚请求
    • 命令中封装了具体的执行过程和回滚过程

  10. 责任链模式

    • 一个请求可能需要多个处理器进行处理，并且请求的发送方并不关心具体哪些处理器最终处理该请求，那么可以使用责任链模式
    • 该模式将使用者和请求的具体处理者相解耦

  11. 装饰模式

    • 装饰类和被装饰类继承相同的接口，并且会提供自己新增的接口，而被修饰对象会被聚合在装饰类中
    • 装饰类是增强类功能的非继承实现，比继承更为灵活，避免子类爆炸

  12. 策略模式

    • 封装一组算法，并且这些算法可以互换，也就是对外提供相同的接口

  13. 适配器模式

    • 将一个现有的类的接口，通过包装的形式，变为当前需要的接口

  14. 迭代器模式

    • 使用迭代器可以访问一个容器对象内的每个元素，而不必了解这些元素在容器中是如何表示的
    • 一般由该容器提供自己实现的迭代器给使用者使用

  15. 组合模式

    • 用来表示树状的层次接口，主要由叶子节点和组合节点共同构成，而用户不用关心是叶子节点还是组合节点

  16. 观察者模式

    • 当一个对象的改变，有多个对象也需要随之而变的时候，可以使用观察者模式
    • 该模式描述的是多对一的依赖

  17. 门面模式

    • 屏蔽系统内部的复杂性，向外提供一个简洁的接口，减小系统之间的依赖

  18. 备忘录模式

    • 对对象的内部状态进行一个快照，并在一定的时机下可以用这个快照恢复对象的状态

  19. 访问者模式

    • 将一个类的数据存储和数据操作相分离，原始的类只负责数据的存储，而由访问者模式决定如何操作这些数据
    • 该模式可以领过的扩展访问对象数据的方式，并且对同一组对象，可以采用完全不同的访问者进行数据操作，并获得完全不同的效果。

  20. 状态模式

    • 当一个类的内部状态改变后，行为也要随之改变时，则可以使用该模式
    • 将状态和行为相绑定，避免繁琐的状态判断

  21. 解释器模式

    • 表示一种语言的语法
    • 并且能够解释该语言下的语句

  22. 享元模式

    • 当系统中有大量的细粒度的对象，而且这些对象创建后状态不会再改变时，可以通过资源池的方式共享这些对象，而不必每次创建一个

  23. 桥梁模式

    • 将抽象和实现相分离。不同于抽象类和实现子类这种继承关系，该模式通过聚合的方式在抽象中调用实现类的方法向外提供功能
    • 抽象和实现可以独立的变化

参考，设计模式之禅

退出移动版