一、模式
模式是在特定环境下人们解决某类重复出现问题的一套成功或有效的解决方案。
A pattern is a successful or efficient solution to a recurring problem within a context.
二、软件模式
- GoF将模式的概念引入软件工程领域,这标志着软件模式的诞生。
- 软件模式呗认为是对开发这一特定 “问题” 的“解法”的某种统一表示。
- 软件模式的基本结构由4各部分构成:
- 在模式发现过程中需要遵循 大三律(Rule of Three),即只有经过3个以上不同类型(或不同领域)的系统的校验,一个解决方案才能从候选模式升格为模式。
三、设计模式
- GoF 对设计模式的定义:
设计模式是在特定环境下为解决某一通用软件设计问题提供的一套定制方案,该方案描述了对象和类之间的相互作用。
Design patterns are descriptions if communicating objects and classes that are customized to solve a general design problem in a particular context.
四、设计模式的基本要素
- 模式名称(Pattern Name)
模式名称 通过一两个词来描述模式的问题、解决方案和效果,以便更好地理解模式并方便开发人员之间交流,绝大多数模式都是根据其功能或模式结构来命名的。
- 问题(Problem)
问题 描述了应该在何时使用模式,它包含了设计中存在的问题以及问题存在的原因。
- 解决方案(Solution)
解决方案 描述了设计模式的组成成分,以及这些组成成分之间的相互关系、各自的职责和写作方式。
- 效果(Consequences)
效果描述了模式应用的效果以及在使用模式时应权衡的问题。
效果主要包含模式的优/缺点分析。
五、设计模式的分类
① 创建型(Creational):创建对象
- 工厂方法模式(Factory Method Pattern)
- 抽象工厂模式(Abstract Factory Pattern)
- 建造者模式(Builder Pattern)
- 原型模式(Prototype Pattern)
- 单例模式(Singleton Pattern)
② 结构型(Structural):处理类 / 对象的组合
- 适配器模式(Adapter Pattern)
- 桥接模式(Bridge Pattern)
- 组合模式(Composite Pattern)
- 装饰模式(Decorator Pattern)
- 外观模式(Facade Pattern)
- 享元模式(Flyweight Pattern)
- 代理模式(Proxy Pattern)
③ 行为型(Behavioral):描述类 / 对象怎样交互、怎样分配职责
- 职责链模式(Chain of Responsibility Pattern)
- 命令模式(Command Pattern)
- 解释器模式(Interpreter Pattern)
- 迭代器模式(Iterator Pattern)
- 中介者模式(Mediator Pattern)
- 备忘录模式(Memento Pattern)
- 观察者模式(Observer Pattern)
- 状态模式(State Pattern)
- 策略模式(Strategy Pattern)
- 模式方法模式(Template Method Pattern)
- 访问者模式(Visitor Pattern)
【注意】 这23种设计模式并非孤立存在,很多模式之间存在联系。
- 例如:在访问者模式种操作对象结构中元素时通常需要使用迭代器模式,在解释器模式中定义终结符表达式和非终结符表达式时可使用组合模式。
- 在开发系统时,应充分发挥每个模式的优势,并使其可以协同工作,完成一些更复杂的工作。
六、设计模式的优点
- 融合了众多专家的经验,提供标准形式(一套通用的设计词汇、一种通用的语言),通俗易懂。
- 使人们可以更加简单、方便地复用成功的设计和体系结构,更容易开发可重用代码。
- 使得设计方案更加灵活,易于修改。
- 提高软件系统的开发效率和软件质量。
七、面向对象设计法则
设计原则名称 | 定义 |
---|---|
单一职责原则(Single Responsibility Principle , SRP) | 一个对象应该只包含单一的职责,并且该职责被完整地封装在一个类中。 |
开闭原则(Open-Closed Principle , OCP) | 软件实体应当对外扩展开放,对修改关闭 |
里氏转换原则(Liskov Substitution Principle , LSP) | 所有引用基类的地方必须能透明地使用其子类的对象 |
依赖倒转原则(Dependence Inversion Principle , DIP) | 高层模块不应依赖底层模块,它们都应依赖抽象。抽象不应该依赖于细节,细节应该依赖于抽象。 |
接口隔离原则(Interface Segregation Principle , ISP) | 客户端不应该依赖那些它不需要的接口。 |
合成复用原则(Composite Reuse Principle , CRP) | 优先使用对象组合,而不是通过继承来达到复用的目的。 |
迪米特法则(Law of Demeter , LoD) | 每一个软件单位对其他单位都只有最少的知识,且极限与那些与本单位密切相关的软件单位。 |