DesignPattern系列文章参考https://www.bilibili.com/video/av24176315/?p=1 李建中讲的 C++ 设计模式,结合自己的学习心得。
如何解决复杂性问题
- 分解:分而治之
- 抽象:忽略他的非本质细节,而去处理泛化和理想化了的对象模型
面向对象
- 重新认识面向对象
- 隔离变化:将变化所带来的影响减为最小
- 各司其职:强调各个类的“责任”,由于需求的变化导致的邢增类型不应该影响到原来类型的实现;
- 对象:语言层面,对象封装了代码和数据;规格曾main,对象是一系列可被使用的公共接口;概念层面,对象是某种拥有责任的抽象。
- 面向对象设计原则
- 依赖倒置原则(DIP)
- 高层模块(稳定)不应该依赖于底层模块(变化),二者都应该依赖于抽象(稳定);
- 抽象不应该依赖于实现细节(变化),实现细节应该依赖于抽象(稳定)。
- 开放封闭原则(OCP)
- 对拓展开放,对修改封闭;
- 类模块应该是可拓展的,但是不可修改。
- 单一职责原则(SRP)
- 一个类应该仅有一个引起它变化的原因;
- 变化的方向隐含着类的责任。
- Liskov 替换原则(LSP)
- 子类必须能替换他们的基类(IS-A);
- 继承表达类型抽象。
- 接口隔离原则(ISP)
- 不应该强迫客户程序以来他们不用的方法;
- 接口应该小而完备。
- 优先使用对象组合,而不是类继承
- 类继承通常为“白箱复用”,对象组合通常为“黑箱复用”
- 继承在某种程度上破坏了封装性,子类父类耦合度高;
- 对象组合原则只要求被组合的对象具有良好的接口定义,耦合度低。
- 封装变化点
- 使用封装来创建对象之间的分界层,一侧修改不对另一侧产生不良影响,从而实现层次间的松耦合。
- 针对接口编程,而不是针对实现编程
- 依赖倒置原则(DIP)
- 重构关键技法
- 按照目的划分
- Creational Pattern
- Structural Pattern
- Behavioral Pattern
- 从范围来看
- 类模型处理类与子类的静态关系;
- 对象模式处理对象间的动态关系。
- 从封装变化角度
- 组件协作模式
框架与应用程序的划分,“组件协作模式”通过晚期绑定
来实现矿建与应用程序之间的松耦合,是二者之间写作时常用的模式。 - “对象创建”模式
通过“对象创建”模式绕开new
,来避免对象创建(new)过程中所导致的紧耦合(依赖具体类),从而支持对象创建的稳定。它是接口抽象之后的第一步工作。- Factory Method
- Abstract Factory
- Prototype
- Builder
- “接口隔离”模式
在组件构建过程中,某些接口之间直接的依赖常常会带来许多问题、甚至根本无法实现。采用添加一层间接(稳定)接口,来隔离本来互相紧密关联的接口是一种常见的解决方案。 - “对象性能”模式
面向对象很好的解决了“抽象”,但付出了不可避免地代价,有时这个成本需要谨慎处理。- Singleton
- Flyweight
- “数据结构”模式
一些组件在内部具有特定的数据结构,如果让客户程序依赖这些特定的数据结构,将极大的破坏组件的复用。将这些特定的数据结构封装在内部,在外部提供统一的接口,来实现与特定数据结构无关的访问,是一种行之有效的解决方案。- Composite
- Iterator
- Chain of Resposibility
- 组件协作模式
赏
使用支付宝打赏
使用微信打赏
若你觉得我的文章对你有帮助,欢迎点击上方按钮对我打赏
扫描二维码,分享此文章