设计模式

发表于 更新于 分类于 阅读次数： Valine：

设计模式随笔

最近复习下设计模式，顺便写下随笔

设计模式的六大原则

  1. 单一职责原则 英文：single responsibility principle,缩写：SRP
    单一职责就是一个借口或类，只完成一个职责
    好处： 类的复杂性降低、可读性提高、可维护性提高、降低变更引起的风险

  2. 里式替换原则
    官方定义：所有引用基类的地方必须能透明的使用其子类对象
    简单的说，就是父类使用的地方，都能用子类替换

  3. 依赖倒置原则
    定义：

    1. 高层模块不应该依赖底层模块，两者都应该依赖期抽象
    2. 抽象不应该依赖细节
    3. 细节应该依赖抽象

    不可分割的原子逻辑就是底层模块，原子逻辑再组装就是高层模块，java中，抽象就是借口或抽象类，细节就是实现类，也就是new 出来的对象

    最精简的定义：面向接口编程

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

  4. 接口隔离原则

    定义： 客户端不应该依赖它不需要的接口，类间的依赖关系应建立在最小接口上

    简单来说就是建立单一接口，功能细化，不要臃肿，不要去实现不必要的接口

  5. 迪米特法则，law of demeter lod，也成最少知识原则(least knowlege priciple lkp)

    一个对象应该对其他对象有对少的了解

    通俗说，一个类不关心耦合类的内部接口，只关心耦合类暴露的方法

    核心：高内聚，低耦合

  6. 开闭原则
    定义： 一个软件实体，如类、模块和函数，应该对扩展开放，对修改关闭

    简单来说，通过新增类扩修改业务代码进行扩展，而非修改功能性代码。

23种设计模式

  1. 单例模式
    定义：确保某一个类只有一个实例，且自行实例化冰箱整个系统提供这个实例

  2. 工厂方法模式

    定义： 定义一个用于创建对象的接口，让子类决定实例化哪一类，工厂方法使用一个类的实例化延迟到其子类

  3. 抽象工厂模式
    定义： 为创建一组相关或相互依赖的对象提供一个接口，而且无需指定他们的具体类

  4. 模板方法模式

    定义：定义一个操作中的算法的框架，将一些步骤延迟到子类中。使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤

  5. 建造者模式

    定义：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示

  6. 代理模式

定义： 为其他对象提供一种代理以控制对这个对象的访问
7. 原型模式

定义： 用原型示例指定创建对象的种类，并且通过拷贝这些原型创建新的对象

java中jdk自带的clone就是

优点： 对象的创建时内存二进制流的拷贝，性能比new对象好

  1. 中介者模式

定义： 用一个中介对象封装一系列的对象交互，中介者使各对象不需要显示的相互作用，从而使其耦合松散，，而且可以独立的改变他们之间的交互

  1. 命令模式

定义：将一个请求封装成一个对象，从而让你使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能

  1. 责任链模式

定义：使多个对象都有机会处理请求，从而避免了请求的发送者和接受者之间的耦合关系。将这些对象连城一条链，并沿着这条链传递该请求，知道有对象处理它为止。

  1. 装饰模式 decorator pattern

定义：动态的给一个对象添加一些额外的职责。就增加功能来说，装饰模式相比生成子类更为灵活

优点：

1. 装饰类和被装饰类可以独立发展，而不会互相耦合
2. 装饰模式是集成关系的一个替代方案
3. 装饰模式可以动态的扩展一个实现类的功能

缺点：剁成的装饰是复杂的

使用场景：

1. 需要扩展一个类的功能，或者给一个类增加附加功能
2. 需要动态的给一个对象增加功能，这些功能可以动态的撤销
3. 需要为一批的兄弟类进行改装或加装功能
  1. 策略模式 strategy pattern

  • 定义：定义一组算法，将每个算法都封装起来，并且使它们之间可以互换

  • 优点：

    1. 算法可以自由切换
    2. 避免使用多重条件判断
    3. 扩展性良好

  • 缺点：

    1. 策略类数量增多
    2. 所有的策略类都需要对外暴露

  • 使用场景：

    1. 多个类只有在算法或行为上稍有不同的场景
    2. 算法需要自由切换的场景
    3. 需要屏蔽算法规则的场景
  1. 适配器模式 adapter pattern
  • 定义：将一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作
  • 优点：
    1. 适配器模式可以让两个没有任何关系的类在一起运行，只要适配器这个角色能够搞定他们就成
    2. 增加了类的透明性
    3. 提高了类的复用度
    4. 灵活性非常好
  • 缺点：
  • 使用场景：后期修改一个接口或类
  1. 迭代器模式 iterator pattern
  • 定义：它提供一种方法访问一个容器对象中各个元素，而又不需暴露该对象的内部细节
  • 优点：
  • 缺点：
  • 使用场景：
  1. 组合模式
  • 定义：
  • 优点：
    1. 高层模块调用简单
    2. 节点自由增加
  • 缺点：
  • 使用场景：维护和展示部分-整体关系的场景
  1. 观察者模式 observer pattern
  • 定义：定义对象间一种一对多的依赖关系，使得每当一个对象改变状态，则所有依赖于它的对象都会得到通知并被自动更新
  • 优点：
    1. 观察者和被观察之间是抽象耦合
    2. 建立一套触发机制
  • 缺点：
  • 使用场景：
  1. 门面模式 facade pattern

  • 定义：要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。

  • 优点：

    1. 减少系统的相互依赖
    2. 提高灵活性
    3. 提高安全性

  • 缺点：

  • 使用场景：

    1. 为一个复杂的模块或子系统提供一个供外界访问的接口
    2. 子系统相对独立——外界对子系统的访问只要黑箱操作即可
  1. 备忘录模式
  • 定义：
  • 优点：
  • 缺点：
  • 使用场景：
  1. 访问者模式 visitor pattern
  • 定义：封装一些作用于某种数据结构中的各元素的操作，它可以在不改变数据结构的前提下定义作用于这些元素的新的操作。
  • 优点：
    1. 符合单一职责远侧
    2. 优秀的扩展性
    3. 灵活性高
  • 缺点：
    1. 具体元素对访问者公布细节
    2. 具体元素变更比较困难
    3. 违背了依赖倒置原则
  • 使用场景：
  1. 状态模式 state pattern

  • 定义：当一个对象内在状态改变时允许其改变行为，这个对象看起来像改变了其类

  • 优点：

    1. 结构清晰
    2. 遵循设计原则
    3. 封装性非常好

  • 缺点：子类太多

  • 使用场景：

    1. 行为随状态改变而改变的场景
    2. 条件、分支判断语句的替代者
  1. 解释器模式 intrpreter pattern
  • 定义：给定一门语言，定义它的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子
  • 优点：
  • 缺点：
    1. 解释器模式会引起类膨胀
    2. 采用递归调用方法
    3. 效率问题
  • 使用场景：
  1. 享元模式 flyweight pattern
  • 定义：使用共享对象可有效地支持大量的细粒度的对象
  • 优点：
  • 缺点：
  • 使用场景：
    1. 系统中存在大象的相似对象
    2. 细粒度的对象都具备较接近的外部状态，而且内部状态与环境无关
    3. 需要缓冲池场景
  1. 桥梁模式 bridge pattern
  • 定义：将抽象和实现解耦，使得两者可以独立地变化
  • 优点：
    1. 抽象和实现分离
    2. 优秀的扩充能力
    3. 实现细节对客户透明
  • 缺点：
  • 使用场景：
    1. 不系统或不适用继承的场景
    2. 接口或抽象类不稳定的场景
    3. 重要性要求较高的场景