2021-05-18

谈谈设计模式

要学习设计模式，有些基础知识是我们必须要先知道的，设计模式是关于类和对象的一种高效、灵活的使用方式，也就是说，必须先有类和对象，才能有设计模式的用武之地，否则一切都是空谈，那么类和对象是从那冒出来的呢？这时就需要比23种设计模式更重要更经典的GRASP模式登场了。

GRASP（General Responsibility Assignment Software Patterns），中文名称为“通用职责分配软件模式”，GRASP一共包括9种模式，如何决定一个系统有多少对象，每个对象都包括什么职责，GRASP模式给出了最基本的指导原则。初学者应该尽快掌握、理解这些原则，因为这是如何设计一个面向对象系统的基础。可以说，GRASP是学习使用设计模式的基础。

1、Infomation Expert（信息专家）

信息专家模式是面向设计的最基本原则，是我们平时使用最多，应该跟我们的思想融为一体的原则。也就是说，我们设计对象（类）的时候，如果某个类拥有完成某个职责所需要的所有信息，那么这个职责就应该分配给这个类来实现。这时，这个类就是相对于这个职责的信息专家。
例如： 常见的网上商店的购物车（ShopCar），需要让每种商品（SKU）只在购物车内出现一次，购买相同商品，只需要更新商品的数量即可。如下图：

针对这个问题需要权衡的是，比较商品是否相同的方法需要放到哪个类里来实现呢？分析业务得知需要根据商品的编号（SKUID）来唯一区分商品，而商品编号是唯一存在于商品类的，所以根据信息专家模式，应该把比较商品是否相同的方法放在商品类里。

2、Creator（创造者）

实际应用中，符合下列任一条件的时候，都应该由类 A 来创建类 B，这时 A 是 B 的创建者：
a、A 是 B 的聚合
b、A 是 B 的容器
c、A 持有初始化 B 的信息（数据）
d、A 记录 B 的实例
e、A 频繁使用 B

如果一个类创建了另外一个类，那么这两个类之间就有了耦合，也可以说产生了依赖关系。依赖或耦合本身是没有错误的，但是他们带来的问题就是在以后的维护中产生连锁反应，而必要的耦合是逃不掉的，我们能做的就是正确的创建耦合关系，不要随便建立类之间的依赖关系，那么该如何去做呢？就是要遵守创建者模式规定的基本原则，凡是不符合以上条件的，都不能随便用 A 创建 B。

3、Low coupling（低耦合）

低耦合模式的意思就是要我们尽可能地减少类之间的连接。

其作用非常重要：

a、低耦合降低了因一个类的变化而影响其他类的范围。

b、低耦合使用类更容易理解，因为类会变得简单，更内聚。

下面这些情况会造成类 A、B 之间的耦合：

a、A 是 B 的属性
b、A 调用 B 的实例的方法
c、A 的方法中引用的 B，例如 B 是 A 方法的返回值或参数。
d、A 是 B 的子类，或者 A 实现 B

关于低耦合，还有下面一些基本原则：

a、Don’t Talk to Strangers 原则

意思就是说，不需要通信的两个对象之间，不要进行无谓的连接，连接了就有可能产生问题，不连接就一了百了了。

b、如果 A 已经和 B 有连接，如果分配 A 的职责给 B 不合适的话（违反信息专家模式），那么就把 B 的职责分配给 A。

c、两个不同模块的内部类之间不能连接，否则比招报应！

4、Polymorphism（多态）

这里的多态跟 OO 三大基本特征之一的“多态”是一个意思。

例如：我们想设计一个绘画程序，要支持可以画不同类型的图形，我们定义一个抽象类 Shape，矩形（Rectangle）、圆形（Round）分别继承这个抽象类，并重写（override）Shape 类里的Draw() 方法，这样我们就可以使用同样的接口（Shape抽象类）绘制出不同的图形，如下图：
这里写图片描述

这样的设计更符合高内聚和低耦合原则，虽然后来我们又增加了一个菱形（Diamond）类，对整个系统结构也没有任何影响，只要增加一个继承 Shape 类就行了。

对设计模式理解

作为一名有追求的程序员，在完成项目的前提下，应该总是希望能够编写出便于阅读、便于扩展、结构良好的代码，简单概括的话，就是编写出优雅的代码。

一些团队在编码规范上，只要求了工程结构分层，并没有对如何编写优雅的代码进行更多的要求。

举个例子，团队可能要求开发Web程序时，工程有如下分层：

Controller：编写控制器；
Business：编写业务；
Dao：编写数据库访问；
Entity：编写实体类；
Util：编写工具类；
其中，以Business为例，团队并没有约定Business中的那些业务实现类如何设计。也许在大团队中，会有专职的架构师来对业务进行需求分析、绘制UML图、编写概要设计、详细设计。但多数团队并没有这样好的条件，更多的时候，是由架构师负责定义好技术架构，研发工程师负责进行需求实现（与业务人员或产品经理对接）。

如果是后面一种情况（研发直接负责需求实现），软件的可扩展性就完全落到研发的身上。

有些团队会因为时间紧张，任务繁重而放弃程序的扩展性，举个例子：一个功能模块编写一个业务实现类。如果是一个长期维护的项目，放弃扩展性可能会在首次研发阶段节省一点时间，但就长远来看，要付出的代价有可能会更多。

所以，如果在编写业务代码时，能自然而然的考虑扩展性，这样才能算是一名合格的软件工程师吧。

因此，我想把我从书本中学到的知识、从实战中收获的经验，进行一次全面的总结，希望自己能从这次总结中学习到更多，也希望总结提到的某一点，能对其他同行起到帮助。

同时，我始终觉得，如果能把一些平时都在做的事情语言化，会使我对我正在做的事情有更进一步的理解。
以我目前对设计模式的理解和实战中的使用，觉得设计模式是使程序具备高内聚低耦合的一种手段。当程序具备了这两种特定，在发生变更时，会使事情变得简单。

简单说说我目前对高内聚低耦合的理解，高内聚是指把相同种类的object都集中一个module中，低耦合是指module与module之间的关联尽量小而轻。

这么说可能比较抽象，如果比较通俗的描述，可以这么理解：

高内聚：有一堆食材和几个筐，我把水果都放到一个筐里（高内聚，因为它功能单一，独立性强。），再把蔬菜都放到第二个筐里，把肉类放到第三个筐里。
低耦合：筐和筐之间做简单的关联，关联范围尽可能小，这样就做到了低耦合。筐中食材的关联也尽可能做到低耦合，食材本身也尽可能做到低耦合。
在开发软件的过程中，尽量找到高内聚和低耦合的平衡点是最关键的