使用工厂方法，有两个检验标准具体产品类不应该相互之间关联产品类里也不应该有相同的代码随着对业务的理解，区分出变与不变的内容，不变的内容需要整合到框架中，不应该在各个产品类里。产品类只需关注自己的逻辑，按照接口要求处理输入和返回值。这样今后即使有新功能接入，开发者也不需要关心整体框架，上手速度快、出问题的概率低。如果有默认的逻辑操作能跑通整个流程，最好有一个基类实现这个逻辑，这样就能最大程度的进行复用。开发过程中需要随着业务的变化和自己对业务的理解不断重构代码，这样才能让代码不成为屎山。

历时大半年，终于写完了《Go设计模式》系列，共30篇文章。感慨颇多，此处做个简单的总结。

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

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

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

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

访问者模式理解比较困难。可以认为对象开了一扇门，用来接收访问者，然后访问者便可在对象内部操作对象。简单来说，对象对访问者进行了授权。这样做能够实现对象和操作的解耦，职责更加单一。对象只管理自身，操作功能安置在访问者中。

迭代器模式从来没有写过，第一次接触迭代器，还是好多年前学C++的STL的时候。当时觉得用迭代器太麻烦了，后来用习惯了觉得真香。UML类图位置：https://www.processon.com/view/link/60d29bf3e401fd49502afd25本文代码链接为：https://github.com/shidawuhen/asap/blob/master/controller/design/23iterator.go1.定义1.1 迭代器模式迭代器模式(Iterator)：

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

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

该模式简单、纯粹、没有太多技巧，但是很好的表达出了设计模式的理念，让读者能够直观的感受到设计模式带来的好处。

模板模式定义算法骨架，使用上有两个特征，一是要继承算法骨架，达到复用的目的；二是具体的算法步骤在子类中实现，达到扩展的目的。UML类图位置：https://www.processon.com/view/link/60d29bf3e401fd49502afd25本文代码链接为：https://github.com/shidawuhen/asap/blob/master/controller/design/19template.go1.定义1.1模板模式模板模式：定义一个操作中的算法的骨架，而将一些步骤延迟到子

终于写完了创建型和结构型设计模式（共12个），现在开始写行为型设计模式（共11个）。观察者模式的应用场景非常广泛，小到代码层面的解耦，大到架构层面的系统解耦，再或者一些产品的设计思路，都有这种模式的影子。UML类图位置：https://www.processon.com/view/link/60d29bf3e401fd49502afd25本文代码链接为：https://github.com/shidawuhen/asap/blob/master/controller/design/18observer.go

享元模式主要是为了复用对象，节省内存。使用享元模式需要有两个前提：享元对象不可变：当享元模式创建出来后，它的变量和属性不会被修改系统中存在大量重复对象：这些重复对象可以使用同一个享元，内存中只存在一份，这样会节省大量空间。当然这也是为什么享元对象不可变的原因，因为有很多引用，变更的话会引起很多问题。UML类图位置：https://www.processon.com/diagraming/609b375407912943913a4c13本文代码链接为：https://github.com/shid

组合模式针对于特定场景，如文件管理、组织管理等，使用该模式能简化管理，使代码变得非常简洁。UML类图位置：https://www.processon.com/diagraming/609b375407912943913a4c13本文代码链接为：https://github.com/shidawuhen/asap/blob/master/controller/design/16composite.go1.定义1.1组合模式组合模式：将对象组合成树形结构以表示‘部分-整体’的层次结构。组合模式使得用户

门面模式也叫外观模式，英文为 Facade Design Pattern。门面模式为子系统提供一组统一的接口，定义一组高层接口让子系统更易用。 门面模式的思想更常用在架构设计上，在编写代码层面大家很少提门面模式，但却一直在默默的使用。UML类图位置：https://www.processon.com/diagraming/609b375407912943913a4c13本文代码链接为：https://github.com/shidawuhen/asap/blob/master/controller/de

前面三篇文章讲了代理模式、桥接模式、装饰器模式，这次讲一下适配器模式。适配器模式比较简单，也比较容易理解。适配器模式可以看作一种“补偿模式”，用来补救设计上的缺陷。应用这种模式算是“无奈之举”。UML类图位置：https://www.processon.com/diagraming/609b375407912943913a4c13本文代码链接为：https://github.com/shidawuhen/asap/blob/master/controller/design/14adapter.go1

装饰器模式主要解决继承关系过于复杂的问题，通过组合来替代继承。它主要的作用是给原始类添加增强功能。 装饰器类和原始类继承同一个父类，这么看感觉和代理模式一样。但其实两者作用不同，装饰器模式主要用于增加功能，代理模式主要用于附加跟原始类无关的功能。本文UML类图链接为：https://www.processon.com/view/link/609b39d6f346fb5a37705da6本文代码链接为：https://github.com/shidawuhen/asap/blob/master/contr

桥接模式并不常用，而且桥接模式的概念比较抽象。桥接模式一般用于有多种分类的情况，如果实现系统可能有多角度分类，每一种分类都有可能变化，那么就把这种多角度分离出来让他们独立变化，减少他们之间的耦合。本文UML类图链接为：https://www.processon.com/view/link/609b39d6f346fb5a37705da6本文代码链接为：https://github.com/shidawuhen/asap/blob/master/controller/design/12bridge.go

前面通过5篇文章讲解了创建型模式，创建型模式主要解决对象的创建问题，封装复杂的创建过程，解耦对象的创建代码和使用代码。Go设计模式(6)-单例模式：用于创建全局唯一对象Go设计模式(7)-工厂模式：用于根据参数，创建不同但是相关类型的对象Go设计模式(8)-抽象工厂：用于创建对象时，减少工厂类个数，增加可维护性Go设计模式(9)-建造者模式：用于创建复杂对象Go设计模式(10)-原型模式：用于创建成本较大的对象从本篇文章开始讲解结构型模式，结构型模式主要总结了一些类或对象组合在一起的经典结构，这些经典的结构

原型模式是创建型模式中的最后一个，它主要用于对象创建成本比较大的情况。本文UML类图链接为：https://www.processon.com/view/link/6080def6079129456d4beecf本文代码链接为：https://github.com/shidawuhen/asap/blob/master/controller/design/10prototype.go1.定义1.1原型模式原型模式：用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。UML类图：1.2分析UML图

这篇文章来讲解比较常用的创建型设计模式-建造者模式。建造者模式主要用来建造复杂的对象。 本文UML类图链接为：https://www.processon.com/view/link/6080def6079129456d4beecf本文代码链接为：https://github.com/shidawuhen/asap/blob/master/controller/design/9builder.go1.定义1.1建造者模式建造者模式：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的

上一篇文章讲解了简单工厂和工厂方法，文章链接为Go设计模式(7)-工厂模式，这篇文章讲一下抽象工厂。抽象工厂不是很常用，主要是因为抽象工厂解决的场景比较特殊，实际开发中很难遇到，但抽象工厂提供了减少类个数、增加系统可维护性的思路，还是很值得借鉴的。本文UML类图链接为：https://www.processon.com/view/link/6080def6079129456d4beecf本文代码链接为：https://github.com/shidawuhen/asap/blob/master/cont

theme: smartblue工厂模式简单来说就是用来创建对象。 工厂模式分为三种更加细分的类型：简单工厂、工厂方法和抽象工厂，一般认为简单工厂是工厂方法的特例，我会通过这篇文章对简单工厂和工厂方法进行讲述。本文UML类图链接为：https://www.processon.com/view/link/6080def6079129456d4beecf本文代码链接为：https://github.com/shidawuhen/asap/blob/master/controller/design/7fa.

1.说明前面5篇文章讲解了设计模式的语法、面向对象分析、原则、代码编写、类图表示法，从本文开始讲述23种设计模式。后面会按照创建型、结构型、行为型的顺序来写创建型5个：单例模式、简单工厂、工厂模式、建造者模式、原型模式 ，主要解决“对象的创建”问题结构型7：代理模式、桥接模式、装饰器模式、适配器模式、门面模式 、组合模式、享元模式，主要解决“类或对象的组合或组装”问题行为型11：观察者模式、模板模式、策略模式、职责链模式、状态模式、迭代器模式、访问者模式、备忘录模式、命令模式、解释器

历经两个月的时间，终于看完了王争的《设计模式之美》。这本书还是很值得一读的，作者对设计理念、设计模式思考的比较深，而且将这些思想运用到实际的工作中，使设计模式显得不那么空；另外这本书花了很大的篇幅来讲设计的理念，讲的比较通透，这是很难得，因为无论哪种设计模式，最终都会映射回理念，设计理念才是根本性的东西。通过阅读设计模式相关的书籍，现在已经完成了5篇文章：Go设计模式(5)-类图符号表示法Go设计模式(4)-代码编写优化Go设计模式(4)-代码编写Go设计模式(3)-设计原则Go设计模式(2

前四章讲解了Go设计模式的一些原理性知识，后面会开始讲23种设计模式。初步计划是对每种模式至少要说明含义、画类图、找实际用例、写代码实现、描述重点信息（使用场景、原因、好处等）。可能大家也看过很多设计模式相关的资料，但看完后或许有似懂非懂的感觉，我想一是因为资料中讲的例子不是特别贴合实际，另一点是因为没有真正的去实现一次代码。所以希望经过写设计模式系列，我自己的设计模式的理解能够更加深入一些。因为要画类图，这部分知识还是本科时候学的，大家可能也记不清了，这次就通过一个例子，把UML类图中的基本元素展示

前段日子写了 Go设计模式(4)-代码编写 但当时写的比较急，文章里代码写的其实并不是很好，所以抽时间又优化了一次。这次虽然还是不完美，但比上次要好不少。这次还有一些优化点，大家可以找一下，看看哪些地方能够继续提升。<?php//工具类class Utils { //返回当前的毫秒时间戳 public function msectime() { list($msec, $sec) = explode(' ', microtime()); $mse

设计原则Go设计模式(3)-设计原则是从相对高的维度来进行代码设计，设计的再好，代码编写不优雅，代码质量也难以得到保障。即使当时写的很好，如何保证随着业务变化、其他同学的修改，代码仍然是优雅的呢？另外，怎样的代码称之为优雅，又让谁来评判呢？所以代码编写至少涉及三个问题：高质量代码的标准是什么？如何编写高质量代码？如何保证代码一直高质量？当然，在代码编写方面，我仍然是个学生，大家要是觉得有价值可以参考一下，如果有错误的地方，也希望大家多多批评指正。1高质量代码的标准代码质量评价有很高的主观性。

上一篇文章Go设计模式(2)-面向对象分析与设计里讲过，做设计最重要的是保留合适的扩展点。如何才能设计出合适的扩展点呢？这篇文章会讲解一下经典的设计原则。这些设计原则大家可能都听过，但可能没有想过为什么会提炼出这些原则，它们有什么作用。对内一个设计原则，我会尽量找到一个实例，说明它的重要性。通过实例来感受原则，比起只看枯燥的文字有效的多。在这里需要说明一点，设计原则是一种思想，设计模式是这种思想的具象化。所以当我们真正领悟到这种思想后，设计的时候会事半功倍。本文要阐述的原则如下：单一职责原则开放

前些日子写完了第一篇设计模式Go设计模式(1)-语法。本篇文章主要讲解遇到项目之后如何做面向对象分析与设计。这篇文章的很多思路都来自于王争的设计模式之美，不过我会按照自己的经验和构思来进行讲解。很多同学都看过设计模式相关的书籍，但是经常很难用到实际工作中，其中一个原因可能是没有想过如何将具体的业务转化为面向对象的流程。一旦我们熟知这个流程，就能从面向过程思维进入到面向对象思维，然后就可以用学到的设计思想对业务进行设计与优化。业务作为一个努力向上的程序员，一天leader告诉你：“为了保证接口调用的安全

简介最近思考了一下这几年写的业务，都是用面向过程思路来实现。之所以用面向过程一是因为大家都这么写，很少去思考是否有更好的实现二是业务简单，使用面向过程编程可以很方便的实现三是业务需要快速上线，面向过程的方法更快更直接但是弊端也很明显，随着业务不断的积累，项目改动起来比较困难，需要不断梳理前人是怎么写的、有什么影响，测试需要做大量的测试，确保功能是正常的。有时候即使是相似或者迭代性的需求也无法保证快速上线。而且即使耗费了大量的人力，也很难保证没有遗漏。这时候就想起面向对象的好。四大特性面向对象编