软件设计模式基础
软件设计模式
软件设计模式定义
软件设计模式是一套被反复使用，经过分类编目的代码设计经验的总结。使用软件设计模式是为了可重用代码、让代码更容易被他人理解、保证代码的可靠性。
软件设计模式定义有如下定义：
- 软件设计模式是对代码设计经验的总结，且经过分类编目。
- 软件设计模式的根本目的是提高代码的重用性和可靠性。代码重用性是指相同功能的代码，不必多次编写。代码可靠性是指增加新功能时，对原来的功能没有影响。可靠性也体现了可扩展和可维护。
- 代码可读性是指编程的规范，便于其他程序员阅读和理解。
基本要素
软件设计模式的基本要素是指模式名称、问题、目的、解决方案、效果、实例代码和相关设计模式等。其中，软件设计模式的基本要素包括以下4个方面。
- 模式名称
- 问题
- 解决方案
- 效果
软件设计模式的基本结构由4部分构成，即问题描述、前提条件（环境或越苏条件）、解法（关联解法和其他相关设计模式）和效果（优/缺点和已知应用），如下
GoF设计模式及其分类
GoF的23中设计模式如下：
| 创建型模式 | 结构型模式 | 行为型模式 | |||
| 类创建型模型 | 对象创建型模式 | 类结构型模式 | 对象结构型模式 | 类行为型模式 | 对象行为模式 | 工厂方法模式 | 类适配器模式 | 对象适配模式 | 职责链模式 |
| 抽象工厂模式 | 桥接模式 | 命令模式 | |||
| 单例模式 | 代理模式 | 迭代器模式 | |||
| 建造者模式 | 组合模式 | 中介模式 | |||
| 原型模式 | 装饰模式 | 备忘录模式 | |||
| 享元模式 | 观察者模式 | ||||
| 外观模式 | 状态模式 | ||||
| 策略模式 | |||||
| 访问者模式 | |||||
| 模板方法模式 | |||||
| 解释器模式 | |||||
创建型设计模式、结构型设计模式和行为型设计模式
软件设计模式有多种分类方法。根据模式目的（模式是用来做什么的）可分为创建型、结构型和行为型3种。
根据软件设计模式的处理范围，可以分为类模式和对象模式两种。
- 类模式处理类和子类之间的关系是通过继承在编译时刻就被确定下来的，这些关系是属于静态的。
- 对象模式是处理对象之间的关系，这些关系是时刻变化运行的，具有动态性。
根据软件设计模式的使用级别，可以分为基本设计模式、常用设计模式和高级设计模式3种。
UML类图
使用UML表示类间的4种基本关系：
关联关系：是类与类之间最常见的一种关系。他是一种结构化关系，用于表示一类对象与另一类对象之间的有（has a）联系。（通俗说是将一个类的对象作为另一个类的属性），在UML类图中，关联关系用实线（或实线带箭头–指向被关联类）连接有关联对象所对应的类。
聚合关系（聚合关系是特殊的关联关系）具有如下特征：
- 当前类对象与成员对象是整体与部分的关系；
- 成员对象可以脱离整体而独立存在；
- 在代码实现时，成员对象可以通过构造器或setter方法注入；
UMl类图表示聚合关系时，使用待空心菱形的实线表示（指向聚合类）。
组合关系（组合关系表示类之间整体和部分的关系，其中整体类可控制成员类的声明周期，部分对象与整体对象之间具有同生共死的关系。）特征如下：
- 当前类对象与成员对象是整体与部分的关系；
- 成员对象与整体对象具有统一的生存期，当整体对象消亡时，成员对象也会消亡；
- 代码实现时，成员对象可在整体类声明或构造方法中实例化；
在UML类图中，组合关系用待实心菱形的直线表示（指向组合类）。
依赖关系：指两个事物之间的一种语义关系，表示一个事物发生变化时会影响另一个事物。依赖关系通常是一种使用关系，为临时性的关联。在代码中，依赖关系是通过定义被依赖类型的局部变量、方法参数及返回值类型等方式来体现。
注意：关联关系使用成员变量（全局变量），而依赖关系使用局部变量。
在UML类图中依赖关系使用带箭头的虚线表示，箭头从使用类指向被依赖的类。
泛化关系（即继承关系，也称”is a”关系。泛化关系用于描述父类与子类之间的关系，父类又称基类或超类，子类又称派生类。
在UML类图的泛化关系使用空心三角形的直线来表示（指向基类）。
实现关系（指接口与实现类之间的实现，可实现接口中声明的所有抽象方法。
在UML类图中使用待空心三角形的虚线来表示实现关系（指向接口）。
面向对象设计原则
面向对象设计原则为支持可维护性复用而诞生，这些原则蕴含在很多设计模式中，它们是从许多设计方案中总结出的指导性原则。设计原则也是学习软件设计模式的基础，每种设计模式都会符合若干设计原则。
| 名称 | 简介 | 重要性 |
|---|---|---|
| 开闭原则 | 软件实体对扩展是开发的，但对修改是关闭的，即在不修改软件实体的基础上扩展其功能 | ★★★★★ |
| 里氏替换原则 | 所有引用基类的地方必须透明地使用其子类对象。或者说，一个可以接收基类对象的地方必然可以接受一个子类对象 | ★★★★★ |
| 依赖倒置原则 | 针对抽象层编程，而不应针对具体类编程 | ★★★★★ |
| 合成-聚合复用原则 | 在关系中应尽量多地使用组合和聚合的关联关系，少使用甚至不使用继承关系 | ★★★★ |
| 单一职责原则 | 类的职责要单一，不能将太多的职责放在一个类中 | ★★★★ |
| 迪米特法则 | 一个软件实体对其他实体的引用应越少越好。或者说，如果两个类不必彼此直接通信，那么这两个类就不因该发生直接的相互作用，而是通过引入一个第三方发生间接交互 | ★★★ |
| 接口隔离原则 | 使用多个专门的接口来取代一个统一的接口 | ★★ |