Go设计模式

最近review代码，感觉工厂方法使用的不准确，正好以此为例聊一下工厂方法的演进。假设我们有一个需求，需要根据不同的信号做不同的事情，如做饭、吃饭。

历时大半年，终于写完了《Go设计模式》系列，共30篇文章。感慨颇多，此处做个简单的总结。因为规划不合理，导致写这个系列耗费了更多时间。

中介者模式是设计模式系列中最后一个模式。这个模式我从未用过，主要原因是没碰到过合适的场景。如果大家有适合使用中介者模式的场景，中介者模式能帮大家更好的维护系统。

解释器模式可以描述如何构建一个简单的“语言”解释器。这个模式只在一些特定的领域才有可能用到，如编译器、规则引擎、正则表达式等。好在解释器模式比较简单，大家可以了解一下。

命令模式很多同学可能不会用到，但这个模式还是蛮有意思的。命令模式能够将操作和数据打包成对象，便于系统对命令进行管理、维护。

初学备忘录模式的时候，特别开心。这不就是游戏里的备份嘛！游戏关闭之后，重新开启，从上次结束的位置继续开始。但终归没有进入游戏行业，也没有机会用过备忘录模式。

访问者模式理解比较困难。可以认为对象开了一扇门，用来接收访问者，然后访问者便可在对象内部操作对象。简单来说，对象对访问者进行了授权。

迭代器模式从来没有写过，第一次接触迭代器，还是好多年前学C++的STL的时候。当时觉得用迭代器太麻烦了，后来用习惯了觉得真香。

状态模式使用的相对较少，主要是因为会引入大量的状态类，导致代码比较难维护。但是合适的场景使用状态模式，可以把复杂的判断逻辑简化。

职责链将处理模块串联成链，请求沿着链条被处理，提供了很好的扩展性，而且能够去掉if-else，方便使用。

策略模式可能是很多同学学习到的第一种模式。这个模式确实适合作为开篇模式来讲，主要原因在于该模式简单、纯粹、没有太多技巧，但是很好的表达出了设计模式的理念，让读者能够直观的感受到设计模式带来的好处。

模板模式定义算法骨架，使用上有两个特征，一是要继承算法骨架，达到复用的目的；二是具体的算法步骤在子类中实现，达到扩展的目的。

终于写完创建型和结构型设计模式（共12个），现在开始写行为型设计模式（共11个）。观察者模式的应用场景非常广泛，小到代码层面的解耦，大到架构层面的系统解耦，再或者一些产品的设计思路，都有这种模式的影子

享元模式主要是为了复用对象，节省内存。使用享元模式需要有两个前提： 享元对象不可变：当享元模式创建出来后，它的变量和属性不会被修改

组合模式针对于特定场景，如文件管理、组织管理等，使用该模式能简化管理，使代码变得非常简洁。希望大家喜欢。

门面模式也叫外观模式，英文为 Facade Design Pattern。门面模式为子系统提供一组统一的接口，定义一组高层接口让子系统更易用。 门面模式的思想更常用在架构设计上。

前面三篇文章讲了代理模式、桥接模式、装饰器模式，这次讲一下适配器模式。 适配器模式比较简单，也比较容易理解。适配器模式可以看作一种“补偿模式”，用来补救设计上的缺陷。应用这种模式算是“无奈之举”。

装饰器模式主要解决继承关系过于复杂的问题，通过组合来替代继承。它主要的作用是给原始类添加增强功能。装饰器类和原始类继承同一个父类，但其实两者作用不同。

桥接模式并不常用，而且桥接模式的概念比较抽象。桥接模式一般用于有多种分类的情况，如果实现系统可能有多角度分类，每一种分类都有可能变化，那么就把这种多角度分离出来让他们独立变化，减少他们之间的耦合。

代理模式能够在不改变原始类（或叫被代理类）代码的情况下，通过引入代理类来给原始类附加功能。 一般代理类和被代理类有同一个父类。