常用设计模式小结
- 2019 年 12 月 26 日
- 筆記
现在你已经准备好迎接一个充满设计模式的崭新世界。 但是，在你打开所有的机会大门之前，我们需要告诉你一些即将在真实世界中遇到的细节–没错，外面的世界还是比较复杂的。来吧，接下来，我们会指引你的方向……
定义设计模式
在看完之前这么多章节的系列，相信作为读者的你已经基本了解什么是设计模式了。但我们至今还未给它一个正式的定义。我们先拿出一个常用的定义：
模式：是在某情境下，针对某问题的某种解决方案。 情境就是应用某个模式的情况。这应该是会不断出现的情况。（例如：你拥有一个对象的集合） 问题就是你想在某情境下达到的目标 ，但也可以是某情境下的约束。（你需要注意走访每个对象，而且不需理会该集合的实现） 解决方案就是你所追求的：一个通用的设计，用来解决约束、达到目标。（将迭代封装进分离的类中）
这是一个需要花些时间逐步理解的定义。在这里，我帮你们找到了一个记忆的方法：
“如果你发现自己处于某个情境下，面对着所欲达到的目标被一群约束影响着的问题，然后，你能够应用某个设计，克服这些约束并达到该目标，将你领向某个解决方案。”
组织设计模式
对着发掘的设计模式数目逐渐增加，有必要将他们分门别类，好将他们组织起来，以简化我们寻找模式的过程，并让同一群组内的模式互相比较。
我们感觉模式的目标分成三个不同类目：创建型、行为型和结构型。
小编先来引导下，这三个类型的基本定义。
创建型模式涉及到将对象实例化，这类模式都提供一个方法，将客户从所需要实例化的对象中解耦。
行为型模式涉及到类和对象如何交互及分配职责。
结构型模式可以让你把类或对象组合到更大的结构中。
现在有了基本的定义，请先停顿下，给自己几分钟时间来给设计模式分类，然后再看下面小编整理的分类。
|
|
|
|
|---|---|---|
|
创建型 |
行为型 |
结构型 |
|
单例（singleton） |
模板方法（Template Method） |
装饰（Decorator） |
|
工厂(Factory Method) |
命令（Command） |
组合（Composite） |
|
抽象工厂（Abstract Factory） |
观察者（Observer） |
适配器（Adapter） |
|
建造者（Builder） |
迭代器（Iterator） |
代理（Proxy） |
|
原型（Prototype） |
状态（State） |
外观（Facede） |
|
|
策略（Strategy） |
享元（Flyweight） |
|
|
中介者（Mediator） |
桥接（Bridge） |
|
|
访问者（Visitor） |
|
|
|
备忘录（Memento） |
|
|
|
解释器（Interpreter） |
|
|
|
责任链（Chain of Responsibility） |
|
其中未加粗部分还没系统学习过，在稍后的章节，还会做一些简单的介绍。
除了刚才的分类之外 ，模式还有另一种分类方式：模式所处理的类或对象
类模式描述类之间的关系如何通过继承定义。类模式的关系是在编译时建立的。
对象模式描述对象之间的关系，而且主要是利用组合定义。对象模式的搞关系通常在运行时建立，而且更加动态、更有弹性。
|
类 |
对象 |
|---|---|
|
模板方法（Template Method） |
单例（singleton） |
|
工厂(Factory Method) |
装饰（Decorator） |
|
适配器（Adapter） |
命令（Command） |
|
解释器（Interpreter） |
组合（Composite） |
|
|
抽象工厂（Abstract Factory） |
|
|
观察者（Observer） |
|
|
建造者（Builder） |
|
|
迭代器（Iterator） |
|
|
代理（Proxy） |
|
|
原型（Prototype） |
|
|
状态（State） |
|
|
外观（Facede） |
|
|
策略（Strategy） |
|
|
享元（Flyweight） |
|
|
中介者（Mediator） |
|
|
桥接（Bridge） |
|
|
访问者（Visitor） |
|
|
备忘录（Memento） |
|
|
责任链（Chain of Responsibility） |
用模式思考问题
小编在这里根据书本，还整理了一份快速指南，可以帮助你开始“用模式思考”。所谓“用模式思考”，意思就是说，能够看着设计，体会在什么地方模式能自然适用，在什么地方模式则不能。
- 保持简单
首先，当你设计时，尽可能地用最简单的方式解决问题。你的目标应该是简单，而不是“如何在这个问题中应用模式”。如果没有使用模式解决某个问题，千万不要以为你就不是一个经验丰富的开发人员。如果你能保持简单的设计，那岂不是更好，甚至你还能得到其他开发人员的欣赏和尊敬呢。
所以，正确的做法就是，为了要让你的设计简单而且有弹性，有时候使用模式是最好的办法，但不是每次都需要使用。
- 设计模式非灵丹妙药
如果所知道的，模式是解决一再发生的问题的通用方案。模式已经被许多开发人员实际测试过。所以，当你需要某个模式的时候，可以放心地使用它，毕竟你知道这个模式已经身经百战。
然后，模式并非灵丹妙药。你需要考虑到模式对你的设计中其他部分所造成的后果。
- 你知道何时需要模式
这是最重要的问题：何时使用模式？当你在设计的时候，如果确定在你的设计中可以利用某个模式解决某个问题，那么就是用这个模式！如果有更简单的解决方案，那么在决定是用模式之前应该先考虑这个方案。
如何知道何时是用一个模式，这就需要经验和知识了。一旦你确定一个简单的解决方案无法满足你的需要，应该考虑这个问题以及相关的约束–这可以帮你将问题对应到一个模式中。如果你对模式有很深的认知，就可能知道有什么模式适合这样的情况。否则，就花些时间调查一下可能会解决这个问题的模式，模式类目中的意图和应用部分会特别有用。
- 拿掉你所不需要的
何时应该删除这个模式呢？当你的系统变得非常复杂，而且并不需要预留任何弹性的时候，就不要使用模式。换句话说，也就是当一个比较简单的解决方案比使用模式更好的时候，你就不需要使用。
- 如果你现在不需要，就别做
如果你今天在设计中有实际的需要去支持改变，就放手采用模式处理这个改变。但是，如果说理由只是假想的，就不要添加这个模式，因为这只会将你的系统搞越复杂，而且很可能你永远都不会需要它。
最后，将模式和描述配对
在这篇文章的最后，还是给大家一个十足的干货，将之前所学的设计模式和描述进行配对，让你对这些常用的模式有一个更加深刻的印象，让你学习有成。
|
模式 |
描述 |
|---|---|
|
装饰者 |
包装一个对象，以提供新的行为 |
|
状态 |
封装了基于状态的行为，并使用委托在行为之间切换 |
|
迭代器 |
在对象的集合之中游走，而不暴露集合的实现 |
|
外观 |
简化一群类的接口 |
|
策略 |
封装可以互换的行为，并使用委托来决定要使用哪一个 |
|
代理 |
包装对象，以控制对此对象的访问 |
|
工厂方法 |
由子类决定要创建的具体类是哪一个 |
|
适配器 |
封装对象，并提供不同的接口 |
|
观察者 |
让对象能够在状态改变时被通知 |
|
模板方法 |
由子类决定如何实现一个算法中的步骤 |
|
组合 |
客户用一致的方式处理对象集合和单个对象 |
|
抽象工厂 |
允许客户创建对象的家族，而无需指定他们的具体类 |
|
命令 |
封装请求成为对象 |
小结
至此，《Head First 设计模式》一书，历时五个月，小编把书中详细介绍的模式基本都学习并输出了一遍。其中，第12章有个复合模式，讲述的是一个MVC使用设计模式的过程，小编还需要消化，也怕输出起来影响大家的学习，故就断了这个念头。
还有11章的代理模式，小编挑选了Hollis在博客上的文章来学习，力求能让大家看的更好，小编在此和大家道歉。很感谢，从头到尾一直和小编学习的读者，设计模式系列，还有最后的输出，小编会继续努力，把这个系列用更好的方式完结。
