一、参考资料
| 书籍名称 |
《设计模式：可复用面向对象软件的基础》 |
| 作者 |
[美] Erich Gamma，[美] Richard Helm，[美] Ralph Johnson |
| 译者 |
李英军、蔡敏、马晓星、刘建中 |
| 出版社 |
机械工业出版社 |
| 出版时间 |
2019-5 |
 |
|
二、软件设计原则
| 设计原则 |
说明 |
| 单一职责原则（Single Responsibility Principle） |
一个类只允许有一个职责，即只有一个导致该类变更的原因。 |
| 开闭原则（Open Closed Principle） |
一个软件实体，如类、模块和函数应该对扩展开放，对修改关闭 |
| 里氏替换原则（Liskov Substitution Principle） |
所有引用基类的地方必须能透明地使用其子类的对象 |
| 迪米特法则（Law of Demeter） |
只与你的直接朋友交谈，不跟“陌生人”说话 |
| 接口隔离原则（Interface Segregation Principle） |
客户端不应该依赖它不需要的接口；类间的依赖关系应该建立在最小的接口上。 |
| 依赖倒置原则（Dependence Inversion Principle） |
上层模块不应该依赖底层模块，它们都应该依赖于抽象；抽象不应该依赖于细节，细节应该依赖于抽象。 |
三、软件设计模式
软件设计模式有三种：创建型模式、结构型模式、行为型模式
3.1创建型模式
| 创建型模式 |
说明 |
| 单例（Singleton）模式 |
某个类只能生成一个实例，该类提供了一个全局访问点供外部获取该实例，其拓展是有限多例模式。 |
| 原型（Prototype）模式 |
将一个对象作为原型，通过对其进行复制而克隆出多个和原型类似的新实例。 |
| 工厂方法（Factory Method）模式 |
定义一个用于创建产品的接口，由子类决定生产什么产品。 |
| 抽象工厂（AbstractFactory）模式 |
提供一个创建产品族的接口，其每个子类可以生产一系列相关的产品。 |
| 建造者（Builder）模式 |
将一个复杂对象分解成多个相对简单的部分，然后根据不同需要分别创建它们，最后构建成该复杂对象。 |
3.2结构性模式
| 结构型模式 |
说明 |
| 代理（Proxy）模式 |
为某对象提供一种代理以控制对该对象的访问。即客户端通过代理间接地访问该对象，从而限制、增强或修改该对象的一些特性。 |
| 适配器（Adapter）模式 |
将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作。 |
| 桥接（Bridge）模式 |
将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现，从而降低了抽象和实现这两个可变维度的耦合度。 |
| 装饰（Decorator）模式 |
动态的给对象增加一些职责，即增加其额外的功能。 |
| 外观（Facade）模式 |
为多个复杂的子系统提供一个一致的接口，使这些子系统更加容易被访问。 |
| 享元（Flyweight）模式 |
运用共享技术来有效地支持大量细粒度对象的复用。 |
| 组合（Composite）模式 |
将对象组合成树状层次结构，使用户对单个对象和组合对象具有一致的访问性。 |
3.3行为型模式
| 行为型模式 |
说明 |
| 模板方法（TemplateMethod）模式 |
定义一个操作中的算法骨架，而将算法的一些步骤延迟到子类中，使得子类可以不改变该算法结构的情况下重定义该算法的某些特定步骤。 |
| 策略（Strategy）模式 |
定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的改变不会影响使用算法的客户。 |
| 命令（Command）模式 |
将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开。 |
| 职责链（Chain of Responsibility）模式 |
把请求从链中的一个对象传到下一个对象，直到请求被响应为止。通过这种方式去除对象之间的耦合。 |
| 状态（State）模式 |
允许一个对象在其内部状态发生改变时改变其行为能力。 |
| 观察者（Observer）模式 |
多个对象间存在一对多关系，当一个对象发生改变时，把这种改变通知给其他多个对象，从而影响其他对象的行为。 |
| 中介者（Mediator）模式 |
定义一个中介对象来简化原有对象之间的交互关系，降低系统中对象间的耦合度，使原有对象之间不必相互了解。 |
| 迭代器（Iterator）模式 |
提供一种方法来顺序访问聚合对象中的一系列数据，而不暴露聚合对象的内部表示。 |
| 访问者（Visitor）模式 |
在不改变集合元素的前提下，为一个集合中的每个元素提供多种访问方式，即每个元素有多个访问者对象访问。 |
| 备忘录（Memento）模式 |
在不破坏封装性的前提下，获取并保存一个对象的内部状态，以便以后恢复它。 |
| 解释器（Interpreter）模式 |
提供如何定义语言的文法，以及对语言句子的解释方法，即解释器。 |
四、心得体会
在我的软件项目开发经验中，令我感触最深的是单一职责原则。单一职责原则是最简单但又最难运用的原则，需要设计人员发现类的不同职责并将其分离，再封装到不同的类或模块中。而发现类的多重职责需要设计人员具有较强的分析设计能力和相关重构经验。下面以大学学生工作管理程序为例介绍单一职责原则的应用。
【例1】大学学生工作管理程序。
分析：大学学生工作主要包括学生生活辅导和学生学业指导两个方面的工作，其中生活辅导主要包括班委建设、出勤统计、心理辅导、费用催缴、班级管理等工作，学业指导主要包括专业引导、学习辅导、科研指导、学习总结等工作。如果将这些工作交给一位老师负责显然不合理，正确的做 法是生活辅导由辅导员负责，学业指导由学业导师负责，其类图如图 1 所示。
总体而言，利用好设计原则和设计模式，能够使我们的代码简洁明了，分工明确，利于后期的维护和修改，是团队协作中及其重要的一环。
