Design Patterns 2 - 面向对象设计原则

https://www.bilibili.com/video/BV1kW411P7KS?p=2

 

重新认识面向对象

理解隔离变化

  • 从宏观层面来看,面向对象的构建方式更能适应软件的变化,能将变化所带来的影响减为最小。

各司其职

  • 从微观层面来看,面向对象的方式更强调各个类的“责任”:画线的责任,自己画自己。接口一致,但是实现不一样。
  • 由于需求变化导致的新增类型不应该影响原来类型的实现——是所谓各负其责

对象是什么?

  • 从语言实现层面来看,对象封装了代码和数据。
  • 从规格层面讲,对象是一系列可被使用的公共接口。
  • 从概念层面讲,对象是某种拥有责任的抽象。

面向对象设计原则
1 依赖导致原则(DIP)

  • 高层模块(稳定)不应该依赖于低层模块(变化),二者都应该依赖于抽象(稳定)。
  • 抽象(稳定)不应该依赖于实现细节(变化),实现细节(变化)应该依赖于抽象(稳定)。

两种实现方式:
MainForm -> Line, Rect(低层模块,容易变化) ->
MainForm(稳定) -->Shape(稳定) <---Line, Rect

第二种实现方式:隔离变化

解决方法:提出抽象类,实现依赖倒置

2 开放封闭原则(OCP)

  • 对扩展开放,对更改封闭
  • 类模块应该是可扩展的,但是不可修改

增加Circle类:
第一种实现:修改:引入了很多改变
第二种方法:增加:扩展的方式应对需求的变化

3 单一职责原则(SRP)

  • 一个类应该仅有一个引起它变化的原因。
  • 变化的方向隐含着类的责任。

4 Liskov替换原则(LSP)

  • 子类必须能够替换它们的基类(IS-A)
  • 继承表达类型抽象

5 接口隔离原则(ISP)

  • 不应该强迫客户程序依赖他们不用的方法。
  • 接口应该小而完备 (protected/private,public的正确使用)

6 优先使用对象组合,而不是类继承

  • 类继承通常为“白箱复用”,对象组合通常为“黑箱复用”
  • 继承在某种程度上破坏了封装性,子类父类耦合度高。
  • 而对象组合只要求被组合的对象具有良好定义的接口,耦合度低。

7 封装变化点:一侧变化,一侧稳定

  • 使用封装来创建对象之间的分界层,让设计者可以在分界层一侧进行修改,而不会对另一侧产生不良的影响从而实现低耦合

8 针对接口编程,而不是针对实现编程

  • 不将变量类型声明为某个特定的具体类,而是声明为某个接口。
  • 客户程序无需获知对象的具体类型,只需要知道对象所提供的接口。
  • 减少系统中各部分的依赖关系,从而实现“高内聚、低耦合”的类型设计方案。
  • 与依赖倒置原则相辅相成,违背一个,往往违背另一个。

产业强盛的标志:接口标准化

将设计原则提升为设计经验
设计习语 Design Idoms

  • Design Idioms描述与特定编程语言相关的低层模式、技巧、惯用法

设计模式 Design patterns

  • Design Patterns主要描述的是“类与相互通信的对象之间的组织关系,包括他们的角色、职责、协作方式等方面。

架构模式 Architectural Patterns

  • Architectural Patterns描述系统中与基本结构组织关系密切的高层模式,包括子系统划分,职责,以及如何组织他们之间关系的规则。
上一篇:初识设计模式


下一篇:Ansible之路——第六章:通配模式Patterns