"本语言的要素都是称为模式的实体。每一模式描述我们周围环境中一再反复发生的某个问题，接着叙述解决这一问题的关键所在。这样，你就能够千百次地重复利用这种解决问题的办法又不会有老调重弹之感。"
最近看了亚历山大.什韦茨（Alexander Shvets）的《深入设计模式》一书，书中涉及的软件设计的细节描述我不太懂，但其中的不少思维方式依然让人深受震撼。
书中提出的核心概念就是“设计模式”，即一种系统解决问题的抽象方法，或者说是常见问题的典型解决方案。人们常常会混淆“模式”和“算法”，但两者并不完全等同。“算法”更像是菜谱，提供达成目标的明确步骤，而“模式”更像是蓝图，你可以看到最终的结果和功能，但需要自己明确实现步骤，来解决反复出现的设计问题。
非常有趣的是，所谓“模式”的概念，最早是由克里斯托弗.亚历山大（Christopher Alexander）在其著作《建筑模式语言》（A Pattern Language）中首次提出的。这本书详细介绍了城镇、邻里、住宅、花园、房间等253个“设计模式”，通过组合与关联，可以形成变化万千的建成环境。
对这点我，我想到了游戏行业的建筑建模水平之所以远超当前绝大多数建筑设计师，也是“模式”在背后发挥了重要价值吧。游戏中，建筑根据风格进行抽象，交互场景需要什么风格的建筑，可以瞬间生成一大片形态各异但风格统一的建筑群，根本就用不着一个个去拉体量、抠细节。
建筑圈子里常常讨论说，设计师几乎已经丧失了在建筑作品中的话语权，一方面是归咎于资本裹挟之类的外因，另一方面，设计师自己也该承担责任，或者可以说，当前的设计教育体系应该承担相当大的责任。被这套体系塑造出的设计师似乎在对形体和概念的追逐中逐渐迷失，放弃了对于设计模式的深入理解和研究。而那些被我们放弃的思维工具，在计算机领域大放异彩，彻底改变了世界的面貌，何其令人感慨。
再回到亚历山大.什韦茨的《深入设计模式》，作者将架构模式之外的所有模式根据其意图或目的分为三种类型：创建型模式、结构型模式，行为模式。具体如下：
创建型模式：
工厂方法 | Factory Method
抽象工厂 | Abstract Factory
生成器 | Builder
原型 | Prototype
单例 | Singleton
结构型模式：
适配器 | Adapter
桥接 | Bridge
组合 | Composite
装饰 | Decorator
外观 | Facade
享元 | Flyweight
代理 | Proxy
行为模式：
责任链 | Chain of Responsibility
命令 | Command
迭代器 | Iterator
中介者 | Mediator
备忘录 | Memento
观察者 | Observer
状态 | State
策略 | Strategy
模板方法 | Template Method
访问者 | Visitor
上述模式的中文名称乍一看让人有点不知所云，英文名称看起来又太过简单。但是深入去了解的话，就会发现这些“模式”的迷人之处。我挑几个简单说说：
抽象工厂 | Abstract Factory
抽象工厂是一种创建型设计模式，它能创建一系列相关的对象，而无需指定其具体类
比如我们要设计一套客厅家具，包括椅子、沙发和咖啡桌。我们可以使用现代（Modern）、维多利亚（Victorian）、艺术装饰（ArtDeco）等不同风格生成这些家具，而且要保证一套家具风格统一。这时候只需要创建一个抽象工厂，该工厂可以生产抽象的椅子、沙发和咖啡桌。用什么风格将其实例化，生产出的就是什么风格的整套家具。
中介者 | Mediator
中介者是一种行为设计模式，能让你减少对象之间混乱无序的依赖关系。该模式会限制对象之间的直接交互，迫使它们通过一个中介者对象进行合作。
比如在施工图绘制过程中，会因为沟通出现很多问题，水电暖专业之间需要协调，结构专业和水专业、暖通专业之间也要就预留洞的位置进行沟通等等，这种网状的沟通看起来似乎很高效，但是，在没有协调模型的情况下，很容易出现各专业信息无法拉通的情况，导致严重的后果。所以，更优的方式是以“建筑专业”作为中介者，结构、给排水、机电、暖通都通过建筑专业进行沟通，而他们之间没有直接沟通。就如同一个机场所有飞机的起飞和降落都通过塔台来协调，而不是各个飞行员之间边飞边商量。
模板方法 | Template Method
模板方法是一种行为设计模式，它在超类中定义了一个算法的框架，允许子类在不修改结构的情况下重写算法的特定步骤。
原来不管是在学校还是工作以后，做设计之前总是习惯去找些案例来看看，觉得哪个跟自己想象中那个模糊的影子比较像，就作为参考，去推进自己的设计。这种方式总是让我很痛苦，我一直在问，这样做出的设计不是随机性很强嘛？如果我这一次恰巧看到的不是这个案例，那做出来的东西就会大不一样。更为糟糕的是，网上的案例浩如烟海，非常容易就迷失掉了。
但其实更好的办法是有一个模板，这个模板不是案例，而是对某一种类型的建筑的一些重要问题提出常规的较优的解决办法，然后再由设计师根据具体的情况去调整细节的处理方式，从统一走向多样。这样看似是限制了创造力，其实不然。模板方法并不会造成千篇一律，反而会在统一中更加多样。
还有一些模式不借助具体的代码或者软件设计的案例不太好说清楚，大家有兴趣可以自己去看。
这些“模式”其实有点类似于瑞.达利欧（Ray Dalio）在《原则》（PRINCIPILES）一书中提到的各种各样的原则。他在做投资决策的时候也不是凭借所谓的经验或者参考案例，而是归纳出在不同情况下评估现状并做出决策的原则，然后基于这些原则在计算机中进行建模，借助于计算机超强的运算能力，帮助人获得更为宏观和客观的视角。这一点真的非常重要。
“总之，没有任何一个模式是孤立存在的。每一个模式在世界上之所以能够存在，只因为在某种程度上为其他模式所支持：每一模式又都包含在较大的模式之中，大小相同的模式都环绕在它的周围，而较小的模式又为它所包含。”
“这就是我们对世界的基本观点，这就是说，当你建造一个东西的时候，你绝不能孤立地来建造它，而且你还必须在它的内部和外界进行整理。这样，一个较大的空间就显得更加紧凑、更加完整了。”
“253个模式汇编成了建筑模式语言。它们创造了一幅有关一个完整区域的有条有理的蓝图，它们有能力创造出千千万万种形式的这样的区域，并在所有的建筑细节上，使之呈现出无穷的多样性。”
