最全golang设计模式

具体处理交给子类

可以控制子类的扩展

封装不变部分，扩展可变部分

提取公共代码，便于维护

行为由父类控制，子类具体实现

增加代码复杂度

AbstractClass（抽象类）

ConcreteClass（具体类）

可以相互配合使用

都能实现算法封装

模版方法模式封装的是算法的骨架，该骨架是不变的，变化的是算法中某些步骤的具体实现；策略模式是把某个步骤的具体实现算法封装起来，所有的封装的算法对象都是等价的，可以相互替换

将实例的生成交给子类

完成类实例化，并将类中的部分对象放到子类中创建，此模式在实例化过程中高效地利用了继承机制。

倒置依赖原则

可以在不知道具体实现情况下编程

更容易扩展对象的新版本

连接平行层次的类层次

具体的产品对象与工厂方法耦合

Product（产品）

AbstractFactory（抽象工厂）

ConcreteProduct（具体的产品）

ConcreteFactory（具体的工厂）

通过复制生成实例

克隆是手段，目的是生成新的对象实例

对客户端隐藏具体的实现类型

在运行时动态改变具体的实现类型

每一个原型子类都必须使用克隆操作

Prototype（原型）

ConcretePrototype（具体原型）

Client（使用者）

将关联零件组装成产品

分离接口和实现

产品簇内的约束是非公开状态

扩展新的产品困难

容易造成类层次复杂

当增加一个新的产品簇时只需要增加一个新的具体工厂，不需要修改源代码，满足开闭原则

当产品簇需要新加新的种类的产品时，则所有的工厂类都需要进行修改，不满足开闭原则

AbstractProduct（抽象产品）

AbstractFactory（抽象工厂）

ConcreteProduct（具体产品）

ConcreteFactory（具体工厂）

工厂方法模式一般是针对单独的产品对象的创建，而抽象工厂模式注重产品簇对象的创建

组合使用，在抽象工厂模式中，具体的工厂实现一般是单例

整体替换算法

算法可以自由切换

避免使用多重条件判断

更好的扩展性

客户端需要了解每种算法的不同，对外保留了策略类

增加了对象数目，策略复用性低

只适合扁平的算法结构

Strategy（策略）

ConcreteStrategy（具体的策略）

Context（上下文）

策略模式是根据需要或者是客户端的要求束选择相应的实现类，各个实现类是平等的，是可以相互替换的。另外策略模式可以让客户端来选择i要使用的策略算法；而状态模式一般是由上下文，或者是在状态实现类里面来维护具体的状态数据，通常不由客户端来指定状态。  

装饰边框与被装饰物的一致性

动态是手段，组合是目的

装饰类和被装饰类可以独立发展，而不会耦合

比继承更加灵活

可以动态地扩展一个实现类

简化高层定义

会产生更多细粒度对象

Componment(组件接口)

ConcreteComponment(具体组件对象)

Decorator（装饰器）

ConcreteDecorator（具体的装饰器）

装饰模式是为了动态地给对象增加功能；组合模式是想要管理组合对象和叶子对象，为它们提供统一一致的操作接口给客户端。

适配器模式是用来改变接口的，而装饰模式是为了改变对象功能

简单窗口

减少系统间的依赖，实现松耦合

提高灵活性，简单易用

提高安全性

增加新的子系统可能需要修改外观类或客户端代码

不能很好地限制客户端使用子系统类

Facade（外观窗口）

各个子系统模块

中介者模式主要用来封装多个对象之间相互的交互，多用在系统内部的多个模块之间；而外观模式封装的是单向的交互，是从客户端访问系统的调用，没有从系统中来访问客户端的调用。

在中介者模式的实现里面，是需要实现具体的交互功能的；而外观模式的实现里面， 一般是组合调用或是转调内部实现的功能，通常外观模式本身并不实现这些功能。中介者模式的目的主要是松散多个模块之间的耦合，把这些耦合关系全部放到中介者中去实现:而外观模式的目的是简化客户端的调用，这点和中介者模式也不同。

发送状态变化通知

实现观察者与目标之间的抽象耦合

实现动态联动

支持广播通信

引起无效的操作

目标与观察者之间依赖关系没有完全解除，而且可能出现循环引用

Subject（被观察对象）

ConcreteSubject（具体的被观察对象）

Observer（观察者）

ConcreteObserver（具体的观察者）

观察者模式是当目标状态发生改变时，触发并通知观察者，让观察者去执行相应的操作。而状态模式是根据不同的状态，选择不同的实现，这个实现类的主要功能就是针对状态相应地操作，它不像观察者，观察者本身还有很多其他的功能，接收通知并执行相应处理只是观察者的部分功能。

共享对象，避免浪费

减少对象数量，节约内存空间

维护共享对象，需要额外开销

Flyweight（享元）

ConcreteFlyweight（具体的享元）

FlyweightFactory（享元工厂）

推卸责任

分离职责是前提，动态组合是精华是目的

请求者与接受者松耦合

动态组合职责

增强了系统的可扩展性和给对象指派职责的灵活性

简化了对象之间的连接

责任分担，每个类只需要处理自己改处理的工作，不处理的传递给下一个对象完成，明确职责

产生很多细粒度的对象

性能较低

调式不方便

一个请求必须被某一个处理者对象所接收，且一个具体处理者对某个请求的处理只能采用以下两种行为之一:自己处理（承担责任）；把责任推给下家处理。

允许出现某一个具体处理者对象在承担了请求的一部分责任后又将剩余的责任传给下家的情况，且一个请求可以最终不被任何接收端对象所接收。

Handler（处理者）

ConcreteHandler（具体的处理者）

语法规则也是类

易于扩展新的语法

易于实现语法

不适合复杂的语法

引起类的膨胀

采用递归方法

效率较低

AbstractExpression(抽象表达式)

TerminalExpression(终结符表达式)

NonterminalExpression(非终结表达式)

Context（上下文）

克里托夫-亚历山大另一部著作《建筑的永恒之道》进一步强化了设计模式的实现，为后来的建筑设计指明了方向

肯特-贝克、沃德-坎宁安将克里托夫的模式实现应用在smalltalk中的图形接口的生成中

软件行业才关注到设计模式并举行多场研讨会

艾瑞克-伽马、理查德-海尔姆、拉尔夫-约翰森和约翰-威利斯迪斯联合出版《设计模式：可复用面向对象软件的基础》，收录了23种设计模式，这是设计模式的里程碑事件，他们称为“四人组”GoF。

每一个模式都有自己的名字，可以根据模式的问题、特点、解决方案、功能和效果来命名。模式名字有助于我们理解和记忆模式，也便于讨论。

问题描述了该模式的应用环境，即何时使用该模式。它解释了设计问题和问题存在的前因后果，以及必须满足的一系列先决条件

模式问题的解决方案包括设计的组成部分、它们之间的相互关系以及各自的职责和写作方式。因为模式就是一个模版，可以应用于多种不同场合，所以解决方案并不描述一个特定而具体的设计或实现，而是提供设计问题的抽象描述和怎么样用一个具有一般意义的元素组合来解决这个问题

描述了模式的应用效果以及使用该模式应该权衡的问题，即模式的优缺点。主要是对时间和空间的衡量，以及该模式对系统的灵活性、扩充性、可移植性的影响，也考虑其实现问题。显式地列出这些效果对理解和评价模式有着很大作用。

工单原建（件）抽

适代（世代）桥装（乔装）外享（外乡）组

描述如何将类或对象按照某种布局组成更大的结构

分类

关注类的实例化

分类

描述程序在运行时复杂的流程控制，即描述多个类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务，他涉及算法与对象间职责分配。

分类

类图

对象图

构件图

部署图

例图

活动图

状态

序列图(顺序图)

具有相同属性、方法和关系的对象抽象，封装了数据和行为。

类的具体实例

一种特殊的类，它具有类的结构但不可被实例化，只能被子类实现。包含抽象操作，但不包含属性，描述了类或组件对外可见的动作

描述类与类之间的关系

关联关系

泛化关系

实现关系

依赖关系

访问一个聚合对象的内容而不需要暴露其实现

遍历任务交给迭代器完成，简化聚合类

支持以不同方式遍历一个聚合，甚至自定义迭代器的子类以支持新的遍历

增加新的聚合类和迭代类都很方便，无需修改原有代码

封装性好，为遍历不同的聚合结构提供了统一的接口

增加了类的个数，增加了系统的复杂性

Iterator（迭代器）

Concretelterator（具体的迭代器）

Aggregate（集合）

ConcreteAggregate（具体的集合）

有迭代器自身控制迭代下一个元素的步骤，客户端无法干预、

特点

由客户端控制迭代下一个元素的步骤，客户端必须显示调用next来迭代下一个元素。

特点

加个“适配器”以便于复用

包装模式

版本升级与兼容

使用继承的适配器

使用委托的适配器

更好的复用性

更好的可扩展性

过多使用适配器，会让系统凌乱，不容易整体把控

Target（对象）

Client（请求者）

Adaptee（被适配）

Adapter（适配）

golang

适配器模式是把两个或者多个接口的功能转换匹配；桥接模式是让接口和实现部分相分离，以便它们可以独立的变化。

两种设计模式在实现上都是使用对象组合，都可以在转调组合对象的功能前后进行附加的处理，但是目的和本质不一样

一般适配器适配过后需要改变接口，如果不改变这不必要适配。装饰模式是不改变接口，装饰模式支持多层递归。

适配模式可以和代理模式组合使用。在实现适配器的时候，通过代理来调用Adaptee，增加灵活性

Singleton（单例对象）

组装复杂的实例

封装性良好，松耦合

建造者独立，容易扩展

便于控制细节风险，更好的复用性

产品的组成部分必须相同，限制使用范围

产品内部变化复杂，会增加很多建造者类

Builder（建造者）

ConcreteBuilder（具体的建造者）

Product（产品）

Director（指导者）

Client（使用者）

golang

可以组合使用。建造者模式的Builder实现中，通常需要选择具体的部件实现。一个可行的方案就是实现成为工厂方法，通过工厂方法来获取具体的部件对象，然后进行部件装配。

抽象工厂模式的主要目的是创建产品簇，这个产品簇里面的单个产品就相当于是构成一个复杂对象的 件对象，H家上对象创建完成后就立即返回整个产品簇，而生成器模式的主要目的是按照构造算法，一步一步来构建个复杂的产品对象，通常要等到整个构建过程结束以后，才会得到最终的产品对象。

模板方法模式主要是用来定义算法的骨架，把算法中某些步骤延迟到子类中实现。再想想生成器模式，Director用来定义整体的构建算法，把算法中某些涉及到具体部件对象的创建和装配的功能，委托给具体的Builder来实现.虽然生成器不是延迟到子类，是委托给Builder.但那只是具体实现方式上的差别，从实质上看两个模式很类似，都是定义一个固定的算法骨架，然后把算法中的某些具体步骤交给其他类来完成，都能实现整体算法步骤和某些具体步骤实现的分离。

这两个模式也有很大的区别，首先是模式的目的，生成器模式是用来构建复杂对象的，而模板方法是用来定义算法骨架，尤其是一些复杂的业务功能的处理算法的骨架；其次是模式的实现，在成容模式是采用委托的方法，而模板方法采用的是继承的方式:另外从使用的复杂度上，生成器模式需要组合Director和Builder对象，然后才能开始构建，要等构建定后才能获得最终的对象，而模板方法就没有这么麻烦，直接使用子类对象即可。

将类的功能层次结构与实现层次结构分离

类的接口与接口的实现相互解耦

抽象和实现分离

良好的扩展能力

实现细节对客户端透明，可动态切换

减少子类个数

由于聚合关系建立在抽象层，要求开发者针对抽象化进行设计和编程，增加了系统的理解和设计难度

Abstraction（抽象化）

RefinedAbstraction（扩展抽象化）

Implementor（实现者）

ConcreteImplementor（具体的实现者）

推送消息

选购场景

策略模式是为了封装一系列算法，使得这些算法可以相互替换；桥接模式是为了分离抽象和实现。

状态模式是为了封装状态对应的行为，并在内部状态改变的时候只改变对象的行为

适配器模式可以用于让两个不兼容的类一起工作。桥接模式通过创建两个不同的继承层次将抽象化对象和实现化对象解耦

容器和内容的一致性

统一了组合对象和叶子对象

简化了客户端调用方式

节点自由增加

难以限制组合中的组件类型

设计较复杂，客户端需要清理类之间的层次关系

不容易用继承的方法来增加构件的新功能

Component（组件容器）

Composite（组合对象）

Leaf（叶子对象）

访问数据结构并处理数据

良好的扩展性

复用性高

分离无关行为，符合单一职责原则

对象结构变化困难

具体元素对访问者公布细节，破坏封装

违背依赖倒置原则

Visitor（访问者）

ConcreteVisitor（具体的访问者）

Element（元素）

ConcreteElement（具体的元素）

ObjectStructure（对象结构）

功能类似都是在不改变原对象结构的情况下修改原对象的功能。装饰模式更多的而是实现对已有功能的加强、修改和完全实现；访问者模式更多的是实现对象结构添加新的功能。

只有一个仲裁者

松耦合

集中控制交互

多对多变为一对多

过度集中，会导致中介者对象变得复杂，后续难以维护和管理

不定义中介者接口，吧具体中介者对象实现成为单例

同事对象不持有中介者，而是在需要的时候直接获取中介者对象并调用

Mediator（中介者）

ConcreteMediator（具体的中介者）

Colleague（同事）

ConcreteColleague（具体的同事）

外观模式多用来封装一个系统内部的多个模块，目的是相关子系统外部提供简单易用的接口，即外观模式封装的是子系统外部与子系统内部模块之间的交互。中介在模式是提供多个平等的同事对象之间交互关系的封装，一般在内部实现。

保存对象状态

更好的封装性

简化原发器

窄接口和宽接口

导致高开销

Originator（发起人）

Memento（备忘录）

Caretaker（备忘录管理员）

Caretaker角色是决定何时拍摄快照，何时撤销以及保存Memento角色。Originator角色职责是生成Memento角色和使用接收Memento角色恢复自身状态。Caretaker角色与Originator角色职责分离。

备忘录模式使用实例表示状态；状态模式使用类表示状态

只在必要时生产实例

通过代理目标对象，把代理对象插入到客户端与目标对象之前，从而为客户端和目标对象引入一定的间接性

存在复杂“大”对象时，代理到必须创建对象时候，才会真的创建

职责清晰

高扩展

低耦合

在客户端和目标对象之间增加一个代理对象，会造成请求处理速度变慢

增加了系统的复杂度

Subject（目标接口）

Proxy（代理）

RealSubject（具体的目标）

类似

不同

类似

不同

命令也是类

类间解耦

可扩展性

Command子类膨胀

Command（命令）

ConcreteCommand（具体的命令）

Receiver（接受者）

Invoker（调用者）

用类表示状态

简化应用逻辑控制

分离状态和行为

显式化进行状态转换

状态类膨胀

State（状态）

ConcreteState（具体的状态）

Context（上下文）

在状态发生改变时触发行为，观察者模式的行为是固定的，通知所有观察者；状态模式是根据状态来选择不同的处理。

观察者模式的目的是在被观察者的状态发送改变的时候，触发观察者联动，具体如何处理观察者不关注；状态模式的主要目的在于根据状态来分离和选择行为。

勃兰特-梅耶于1988年著作《面向对象软件构造》提出

软件实体应当对扩展开放，对修改关闭

对软件测试的影响

可以提升代码的复用性

提高代码的可维护性

通过“抽象约束、封装变化”实现。即通过接口或抽象类为软件实体定义一个相对稳定的抽象层，而将相同的可变因素封装找相同的具体实现类中。

里斯科夫女士在1987年的“面向对象技术的高峰会议”发表文章《数据抽象和层次》提出。

继承必须确保超类所拥有的性质在子类中仍然成立

里氏替换原则是开闭原则的补充，是对实现抽象化的具体步骤的规范

里氏替换原则是实现开闭原则的重要方式之一

它克服了继承在哪个重写父类造成的可复用性变差的缺点

它是动作正确性的保障。即类的扩展不会给已有的系统引入新的错误，降低了代码的出错可能性

子类可以扩展父类的功能，但不能改变父类原有的功能。即子类继承父类时，除添加新的方法完成新增功能外，尽量不要重写父类的方法。

罗伯特-马丁于1996年在C++ Report上发表文章提出

高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。

核心就是面向接口编程，不要面向实现编程

依赖倒置原则是实现开闭原则的重要途径，他降低了客户与实现模块之间的耦合

降低类间的耦合性

提高系统的稳定性

减少并行引发的风险

提高代码的可读性和可维护性

每个类尽量提供接口或抽象类，或者两者都具备

变量的声明类型尽量是接口或者抽象类

任何类都不应该从具体类派生

使用继承时尽量遵循里氏替换原则

罗伯特-马丁于2002年提出

客户端不应该被迫依赖于它不使用的方法

一个类对另一个类的依赖应该建立在最小的接口上

要为各个类建立它们需要的专用接口，而不要视图建立一个庞大的接口供所有依赖它的类去调用

为了约束接口，降低类对接口的依赖

将臃肿庞大的接口分解为多个粒度小的接口，预防外来变更的扩散，提高系统的灵活性和可维护性

接口隔离提高了系统的内聚性，减少了对外交互，降低了系统的偶合性

如果接口粒度大小定义合理，能够保证系统的稳定性；但是如果定义过小，接口数量过多，设计复杂；定义过大，灵活性降低，无法提供定制服务。

使用多个专门的接口还能够体现对象的层次，因为通过接口的继承，实现对中接口的定义

能够减少项目工程的代码冗余

接口尽量小，但是要有限度

为依赖接口的类定制服务

了解环境，拒绝盲从

提高内聚，减少对外交互

单一职责原则

罗伯特-马丁于2003年在《敏捷软件开发:原则、模式与实践》提出

一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分

核心是控制类的粒度大小、将对象解耦、提高其内聚性

降低类的复杂度

提高类的可读性

提高系统的可维护性

变更引起的风险降低

发现类的不同职责并将其分离，再封装到不同的类或模块中

迪米特法则

1987年伊恩-荷兰在进行迪米特项目研究时提出

如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。

目的是为了降低类之间的耦合度，提高模块的相对独立性

降低了类之间的耦合度，提高了模块的相对独立性

由于耦合度降低，从而提高了类的可复用率和系统的扩展性

依赖者

被依赖着

组合/聚合复用原则（CARP）

在软件复用时，要尽量使用组合或聚合等关联关系来实现，其次才考虑继承关系来实现

如果要使用继承关系，则必须严格遵循里氏替换原则。合成复用原则与里氏替换原则相辅相成，都是开闭原则的具体实现规范

组合、聚合维持了类的封装性

新旧类之间的耦合度低

复用的灵活度高

通过将已有的对象纳入新对象中，作为新对象的成员来实现的，新对象可调用已有对象的功能，从而达到复用。