薯拾

design-pattern

2019-12-10

DesignPattern系列文章参考https://www.bilibili.com/video/av24176315/?p=1 李建中讲的 C++ 设计模式,结合自己的学习心得。

如何解决复杂性问题

  • 分解:分而治之
  • 抽象:忽略他的非本质细节,而去处理泛化和理想化了的对象模型

    面向对象

  • 重新认识面向对象
    1. 隔离变化:将变化所带来的影响减为最小
    2. 各司其职:强调各个类的“责任”,由于需求的变化导致的邢增类型不应该影响到原来类型的实现;
    3. 对象:语言层面,对象封装了代码和数据;规格曾main,对象是一系列可被使用的公共接口;概念层面,对象是某种拥有责任的抽象。
  • 面向对象设计原则
    1. 依赖倒置原则(DIP)
      • 高层模块(稳定)不应该依赖于底层模块(变化),二者都应该依赖于抽象(稳定);
      • 抽象不应该依赖于实现细节(变化),实现细节应该依赖于抽象(稳定)。
    2. 开放封闭原则(OCP)
      • 对拓展开放,对修改封闭;
      • 类模块应该是可拓展的,但是不可修改。
    3. 单一职责原则(SRP)
      • 一个类应该仅有一个引起它变化的原因;
      • 变化的方向隐含着类的责任。
    4. Liskov 替换原则(LSP)
      • 子类必须能替换他们的基类(IS-A);
      • 继承表达类型抽象。
    5. 接口隔离原则(ISP)
      • 不应该强迫客户程序以来他们不用的方法;
      • 接口应该小而完备。
    6. 优先使用对象组合,而不是类继承
      • 类继承通常为“白箱复用”,对象组合通常为“黑箱复用”
      • 继承在某种程度上破坏了封装性,子类父类耦合度高;
      • 对象组合原则只要求被组合的对象具有良好的接口定义,耦合度低。
    7. 封装变化点
      • 使用封装来创建对象之间的分界层,一侧修改不对另一侧产生不良影响,从而实现层次间的松耦合。
    8. 针对接口编程,而不是针对实现编程
      • 不将变量类型声明为某个特定的具体类,而是声明为某个接口;
      • 客户程序无需获知对象的具体类型,只需要知道对象所具有的接口。
      • 减少系统中各部分的依赖关系,从而实现“高内聚,低耦合”。

        Before

        重构获得设计模式;代码中经常改变的地方使用设计模式
  • 重构关键技法
    1. 静态–>动态
    2. 早绑定–>晚绑定
    3. 继承–>组合
    4. 编译时依赖–>运行时依赖
    5. 紧耦合–>松耦合

      模式归类

  • 按照目的划分
    1. Creational Pattern
    2. Structural Pattern
    3. Behavioral Pattern
  • 从范围来看
    1. 类模型处理类与子类的静态关系;
    2. 对象模式处理对象间的动态关系。
  • 从封装变化角度
    1. 组件协作模式
      框架与应用程序的划分,“组件协作模式”通过晚期绑定来实现矿建与应用程序之间的松耦合,是二者之间写作时常用的模式。
    2. “对象创建”模式
      通过“对象创建”模式绕开new,来避免对象创建(new)过程中所导致的紧耦合(依赖具体类),从而支持对象创建的稳定。它是接口抽象之后的第一步工作。
    3. “接口隔离”模式
      在组件构建过程中,某些接口之间直接的依赖常常会带来许多问题、甚至根本无法实现。采用添加一层间接(稳定)接口,来隔离本来互相紧密关联的接口是一种常见的解决方案。
    4. “对象性能”模式
      面向对象很好的解决了“抽象”,但付出了不可避免地代价,有时这个成本需要谨慎处理。
    5. “数据结构”模式
      一些组件在内部具有特定的数据结构,如果让客户程序依赖这些特定的数据结构,将极大的破坏组件的复用。将这些特定的数据结构封装在内部,在外部提供统一的接口,来实现与特定数据结构无关的访问,是一种行之有效的解决方案。
      • Composite
      • Iterator
      • Chain of Resposibility
使用支付宝打赏
使用微信打赏

若你觉得我的文章对你有帮助,欢迎点击上方按钮对我打赏

扫描二维码,分享此文章