重新温习软件设计之路（4）

本文是我学习课程《软件设计之美》的学习总结第四部分，记录对于设计模式和简单设计的理解。

上一篇：体会软件设计之美（3）

1 关于设计模式

上一篇重新理解了面向对象的三大特点及SOLID五大设计原则之后，我们知道了，设计原则是道，是一个可以树立在我们心中的标尺，作为一个标准指导我们的设计。那么，我们常常听到的设计模式就可以算作是术，他们是一个一个针对特定的普遍存在的问题给出的解决方案。

郑晔老师的《软件设计之美》课程其实并没有主要讲解23种设计模式，但他针对设计模式本质的理解和讲解，可以说是对我们醍醐灌顶的指导。有了对于整体的理解认知，再去找相关的资料去学习理解那些设计模式，就会不再难懂。

设计模式的发展简史

模式，就是针对一些普遍存在的问题给出的特定解决方案。

模式源起建筑领域，墙里开花墙外香，它在软件行业流行开来。

设计模式的发展历史，我总结为了一张脑图如下所示：

设计模式的理解误区

对设计模式的第一个常见误区就是：设计模式只有23种。

其实，所谓的23个设计模式就是23个例子，设计模式不止23种。

在特定场景下，可能会延伸出一些新的设计模式。

对设计模式的第二个常见误区就是：我们需要将23种设计模式全部学习一遍。

其实，虽然这23个设计模式都很流行，但是有些模式，如果我们不是编写特定的代码，很可能根本用不上。

郑晔老师强调，学习设计模式不宜贪多求全！学习设计模式最重要的其实是要了解模式的应用场景。

关于哪些是常用的设计模式，哪些不常用，可以参考王争老师的《设计模式之美》中提供的列表，如下图所示：

图片源自《设计模式之美》

设计原则与设计模式的关系

用数学来比喻的话，设计原则就是公理，是讨论问题的基础。设计模式是定理，是在特定场景下，对于经常发生的问题给出的一个可复用的解决方案。

因此，你可以知道，理解设计原则远比学习23种设计模式重要。因为，你在根据设计原则指导设计的时候，可能在不经意的重构调整使之符合设计原则的时候，就已经成为某种你所熟悉的设计模式了。由此可以看出，设计原则是这些模式背后的底层逻辑，设计模式就是在某个特定场景下符合某个或多个原则的解决方案。

当然，当你发出“我擦，原来这就是xxxx模式”的时候，前提是你事先知道和了解过这些设计模式。所以，我个人认为，如果我们已经学过了23种设计模式，不妨将根据常用和不常用的列表，把常用的模式再过一遍，然后将原则重新理解一遍，最后忘记模式谨记原则，在设计实践中慢慢根据原则去调整。

这个剧情是不是有点熟悉？对，你可能在《倚天屠龙记》里面看过这样的一个剧情，张无忌回武当面临武当派被赵敏派出的高手欺负，张三丰也被阴招所伤。在此危难之际张无忌假装武当小弟子混入张三丰身旁，现学现卖武当剑法，当张三丰快速演示完武当剑法之后，问张无忌记住了多少，张无忌回答从70%到0%说道“已经忘得差不多了”，没想到张三丰竟然笑着说“不赖不赖，忘得真快”。最后的结果我们也都知道了，张无忌还是以武当剑法敌退赵敏的几大高手。

那么，为什么张无忌可以在将武当剑法忘得干干净净的前提下还是以武当剑法击退了各大高手呢？因为，张无忌有九阳神功这种内在心法护体，学什么都很快，而且直接本质，抓住了神，那么形也只是时间和实践问题。张无忌在和各路高手的PK中，虽然也有被伤，但是不断地在调整自己的剑术向武当剑法的精髓靠近，这和我们以设计原则作为指导方针，在设计实践中不断调整自己的设计朝着原则靠拢而不经意间实现了某种设计模式其实是一样的道理。

整体脑图

最后，整理了这部分学习内容的脑图如下所示：

整理自《软件设计之美》

2 关于简单设计

在工作中，我的领导曾经教导我不要用力过猛，不要过度设计。因此，我们曾经在一段时间内整体学习了TDD这种实践方式，但因为学艺不精和进度吃紧，最终我们放弃了TDD，但还是保留了编写单元测试和单元测试覆盖率的硬性要求。

如何把握设计发力的大小，其实也有一些启发性的规则来帮助我们把握。

偏思维层面

KISS原则（Keep it simple, stupid）
YAGI原则（You aren't gonna need it）
DRY原则（Don't repeat yourself）

偏工作层面

简单设计原则（Simple Design），它有四条具体的规则：

通过所有测试

代码语言：txt复制

-  要求我们有配套的自动化测试，并且保证测试覆盖了大多数场景

消除重复

代码语言：txt复制

-  发现重复，对分离关注点有深刻的认识

表达出程序员的意图

代码语言：txt复制

-  编写有表达性的代码

让类和方法的数量最小化

代码语言：txt复制

-  不要过度设计

从Why开始思考

根据个人在工作中的实践经历发现，作为开发者我们往往在接到各种需求的时候会从认识需求是什么开始，到怎么做结束，从而一股脑地接了很多后来发现没有实际用处的需求，也做了很多过度的设计。而要真正做到避免过度设计，最重要的还是需要了解这个需求为什么要做？是否真的要做？如果真的要做，再用简单设计的指导规则去做简单的设计然后开始演化。这种思维方式的转变其实已经被Simon Sinek在著作《Start With Why》中提出了黄金圈的概念中展示出来了。在这个黄金圈中，从外到内依次是What、How和Why。我们开发者大部分人在日常开发工作中的思考方式其实是由外到内的，由于各种原因或限制，我们往往在了解了What之后就直接调到了How，最后就开始编码测试急着交付了。而业界大佬们建议的则是，由内向外，先默认需求为不接，直到弄清楚Why为什么要做这个需求之后，再去做简单设计进行演化。