GRASP 、SOLID 与 GoF 设计模式

一、GRASP

GRASP：通用职责分配软件设计模式(General Responsibility Assignment Software Patterns)，其主要思想是基于单一职责设计软件对象。

思考软件对象设计以及大型构件的流行方式是，考虑其职责、角色和协作。这是被称为职责驱动设计（RDD）的一部分。

在RDD中，我们认为软件对象具有职责，即对其所作所为的抽象。UML把职责定义为“类的协约或义务”。就对象角色而言，职责与对象的义务和行为相关。在对象设计中，职责被分配给对象类。对于软件领域对象来说，由于领域模型描述了领域对象的属性和关联，因此其通常产生与“认知”相关的职责。

职责的粒度会影响到类和方法的转换。大粒度职责具有数百个类和方法，而小粒度可能只有一个方法。职责与方法并非同一事物，职责是一种抽象，而方法只是实现了职责。

RDD也包括了协作的思想。职责借助于方法来实现，该方法即可以单独动作，也可以与其他方法和对象协作。

RDD是思考OO软件设计的一般性隐喻。把软件对象想象成具有某种职责的人，他要与其他人协作以完成工作。RDD使我们把OO设计年作是有职责对象进行协作的共同体。

职责分为二种类型：行为和认识。

对象的行为职责包括：

自身执行一些行为，如创建对象或计算。
初始化其他对象中的动作。
控制和协调其他对象中的活动。

对象的认知职责包括：

对私有封装数据的认知。
对相相关对象的认知。
对其他能够导出或计算的事物的认知。

有经验的OO开发者建立了既有通用原则又有惯用方案的指令系统来指导他们编制软件。如果以结构化形式对这些问题、解决方案和命名进行描述使其系统化，那么这些原则和习惯用法就可以称为模式。

共有9个GRASP模式：

创建者（Creator）
信息专家（Information Expert）
控制器（Controller）
低耦合（Low Couping)
高内聚（High Cohesion）
多态性（Polymorphism）
纯虚构（Pure Fabrication）
间接性（Indirection）
防止变异（Protected Variations）

二、SOLID 原则

SOLID是由罗伯特·C·马丁在21世纪早期引入的记忆术首字母缩略字，代表面向对象编程和面向对象设计的五个基本原则。当这些原则被一起应用时，它们让设计和开发一个容易维护和可扩展的系统变得更加容易。

S：单一责任原则(SRP)，Single Responsibility Principle
O：开放封闭原则(OCP)，Open-Closed Principle
L：里式替换原则(LSP)，Liskov Substitution Principle
I：接口分离原则(ISP)，Interface Segregation Principle
D：依赖倒置原则(DIP)，Dependency Inversion Principle

S、单一职责原则（Single Responsibility Principle, SRP）

单一职责原则（Single Responsibility Principle, SRP）：一个类应该有且只有一个引起它变化的原因。简单地说：接口职责应该单一，不要承担过多的职责。

职责，可以理解为"引起变化的原因"。往往我们需要修改代码以应对需求变更，如果职责越多，职责间存在耦合越大，意味着可能潜在的变化点越多，变化的概率和风险越大，导致实现改变的需求难度越大。职责过多怎么办？拆！拆！拆！如果在设计过程中发现一个类承担的职责太多，最直接有效的解决方式就是按职责 "拆分"。

这一思想可以看成是第一点中RDD设计思想的延申，设计单一职责的对象。

O、开放封闭原则（Open Closed Principle，OCP）

开放封闭原则（Open Closed Principle，OCP）的定义是：一个软件实体，如类、模块和函数应该对扩展开放，对修改关闭。允许通过扩展的方式增加系统行为，禁止通过直接修改源码的方式增加系统行为。简单地说：就是当别人要修改软件功能的时候，他不能修改我们原有代码，只能新增代码实现软件功能修改的目的。

L、里氏替换原则（Liskov Substitution Principle，LSP）

里氏替换原则（Liskov Substitution Principle，LSP）的定义是：所有引用基类的地方必须能透明地使用其子类的对象。简单地说：所有父类能出现的地方，子类就可以出现，并且替换了也不会出现任何错误。

I、接口分离原则（Interface Segregation Principle，ISP）

接口分离原则（Interface Segregation Principle，ISP）的定义是：类间的依赖关系应该建立在最小的接口上。简单地说：接口的内容一定要尽可能地小，能有多小就多小。

D、依赖倒置原则（Dependency Inversion Principle，DIP）

依赖倒置原则（Dependency Inversion Principle，DIP）的定义：高层模块不应该依赖底层模块，两者都应该依赖其抽象。抽象不应该依赖细节，即接口或抽象类不依赖于实现类，细节应该依赖抽象，即实现类不应该依赖于接口或抽象类。简单地说，就是说我们应该面向接口编程，通过抽象成接口，使各个类的实现彼此独立，实现类之间的松耦合。

三、GoF 设计模式

在 1994 年，由 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides 四人合著出版了一本名为 Design Patterns - Elements of Reusable Object-Oriented Software（中文译名：设计模式 - 可复用的面向对象软件元素） 的书，该书首次提到了软件开发中设计模式的概念。

四位作者合称 GOF（四人帮，全拼 Gang of Four）。他们所提出的设计模式主要是基于以下的面向对象设计原则。

对接口编程而不是对实现编程。
优先使用对象组合而不是继承。

设计模式是一套被反复使用的、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了重用代码、让代码更容易被他人理解、保证代码可靠性。毫无疑问，设计模式于己于他人于系统都是多赢的，设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石一样。项目中合理地运用设计模式可以完美地解决很多问题，每种模式在现实中都有相应的原理来与之对应，每种模式都描述了一个在我们周围不断重复发生的问题，以及该问题的核心解决方案，这也是设计模式能被广泛应用的原因。

设计模式在软件开发中的两个主要用途。

1、开发人员的共同平台

设计模式提供了一个标准的术语系统，且具体到特定的情景。例如，单例设计模式意味着使用单个对象，这样所有熟悉单例设计模式的开发人员都能使用单个对象，并且可以通过这种方式告诉对方，程序使用的是单例模式。

2、最佳的实践

设计模式已经经历了很长一段时间的发展，它们提供了软件开发过程中面临的一般问题的最佳解决方案。学习这些模式有助于经验不足的开发人员通过一种简单快捷的方式来学习软件设计。

3、设计模式的类型

根据设计模式的参考书 Design Patterns - Elements of Reusable Object-Oriented Software（中文译名：设计模式 - 可复用的面向对象软件元素）中所提到的，总共有 23 种设计模式。这些模式可以分为三大类：创建型模式（Creational Patterns）、结构型模式（Structural Patterns）、行为型模式（Behavioral Patterns）。

序号	模式 & 描述	包括
1	创建型模式这些设计模式提供了一种在创建对象的同时隐藏创建逻辑的方式，而不是使用 new 运算符直接实例化对象。这使得程序在判断针对某个给定实例需要创建哪些对象时更加灵活。	工厂模式（Factory Pattern）抽象工厂模式（Abstract Factory Pattern）单例模式（Singleton Pattern）建造者模式（Builder Pattern）原型模式（Prototype Pattern）
2	结构型模式这些模式关注对象之间的组合和关系，旨在解决如何构建灵活且可复用的类和对象结构。	适配器模式（Adapter Pattern）桥接模式（Bridge Pattern）过滤器模式（Filter、Criteria Pattern）组合模式（Composite Pattern）装饰器模式（Decorator Pattern）外观模式（Facade Pattern）享元模式（Flyweight Pattern）代理模式（Proxy Pattern）
3	行为型模式这些模式关注对象之间的通信和交互，旨在解决对象之间的责任分配和算法的封装。	责任链模式（Chain of Responsibility Pattern）命令模式（Command Pattern）解释器模式（Interpreter Pattern）迭代器模式（Iterator Pattern）中介者模式（Mediator Pattern）备忘录模式（Memento Pattern）观察者模式（Observer Pattern）状态模式（State Pattern）空对象模式（Null Object Pattern）策略模式（Strategy Pattern）模板模式（Template Pattern）访问者模式（Visitor Pattern）