Go学设计模式--装饰器和职责链，哪个模式实现中间件更科学

大家好，我是每周都在这里和大家一起进步的站长~这一次，我们将继续填补漏洞，并谈论装饰模式

上一篇文章我们说了decorator是agent模式的特殊应用，很多人说中间件是decorator模式实现的，也有人说是责任链实现的所以在本文中我们来看看它们的异同

什么是室内设计师。

装饰模式，也称为包装模式，指的是在不改变原有对象的情况下，动态地向一个对象添加一些额外的职责就添加功能而言，decorator模式比生成子类更灵活，属于结构化设计模式

向对象添加新行为最简单直观的方法是扩展本体对象，通过继承来达到目的。但是使用继承不可避免地有以下两个缺点:

继承是静态的，并且已经在编译期间被确定，所以它不能在运行时改变对象的行为。

一个子类只能有一个父类当需要添加太多新功能时，类的数量会急剧增加

使用decorator模式，我们通过将新行为放置在实现相同windows套接字的包装器对象中，来动态地将新行为添加到现有对象中我们的代码在包装器中的扩展，有助于在不修改现有对象代码的情况下重用函数，符合开闭原则

这里放在包装器对象中的现有对象通常称为组件，包装组件的包装器对象就是我们常说的装饰器因为decorator实现的是同一个接口，客户端无法识别两者的区别，所以添加decorator时不需要修改客户端的调用代码

从上面对装饰器模式的描述中，可以感觉到它非常类似于代理模式这是因为它们在结构上几乎是一样的，装饰器是代理的一个特殊应用——装饰器模式的一个特点是可以嵌套多层装饰器，相当于给代理添加了代理但是agent强调的是本体对象的访问控制，而decorator是用来增强局部区域的，两者目的不同

上面用文字描述了decorator模式的有用特性，下面用UML类图展示一下它的结构，让我们在编写代码之前对模式中的每个角色有一个更清晰的了解。

装饰品的结构

使用UML类图来表示装饰模式的结构如下:

从图中可以看出，装饰者模式主要有以下角色:

客户端:会使用多层decorators封装组件，最后调用装饰好的包装器方法开始执行。

Component: Component声明由装饰器对象和被装饰的组件对象实现的公共接口。

组件实现:具体的组件实现类在其操作方法中定义了组件的基本行为，装饰类可以增强这些行为。

装饰类:有一个指向封装对象的成员变量在自己的操作方法中调用被修饰对象的操作方法

具体装饰类:覆盖父类的操作方法，实现增强的逻辑要实现的主要逻辑已经在类图中给出了第四步的基础装修类不需要存在具体的装饰类完全可以持有对被装饰对象的引用，实现增强的逻辑，这样整体结构会更简单

注意:图中的方法名可以在代码实现中自行定义，不需要与图中给出的方法名完全相同。

我们可以和上一节代理模式的UML类图做一个比较它们在结构上非常相似，尤其是省略了BaseDecorator这一层之后，结构上基本相同

让我们看一下实现装饰模式的代码模板本文提供了一个代码模板，用于在Go语言中实现一个简单的装饰模式

装饰模式的代码实现

知道了decorator模式结构的组成后，写代码就清楚多了接下来，让我们演示一个使用装饰模式来增强游戏控制台的例子

首先我们定义一个游戏主机的产品接口，就是上面类图中组件和装饰器的通用接口。

//PS5产品接口类型PS5接口startgpuenginegettpriceint64

然后我们提供一个基本的产品实现类作为装饰模式中的一个组件。

这是游戏机的光盘版平时玩游戏的同学都会知道，一般会有数字版的主机，会便宜一些在这种情况下，我们可以提供一个数字版本的游戏主机作为组件实现类

//PS5数字主机type PS5 with digitalstructfuncstargpoenginefmt . printlnfunctpriceint 64 return 3600

那么除了这两种基本的产品类型，厂商一般会开发各种主题和配色有限的主机，增加硬件配置的主机等这两种在价格上肯定会和基础版有些区别我们可以使用decorators来实现这种级别的扩展，从而避免基本组件类的改变

下面是用两个decorators实现的Plus版本和主题配色版本的两个增强。

根据装饰者模式的特点，这两种增强也可以叠加在一起，形成一个高主题的限量版主机...诶，是不是有点像游戏厂商每年发新机给你的感觉，就是出不了二代，每年给你发几款限量配色，升级到下一屏，意思是你XXX。

好了，在客户端，我们可以通过装饰器和组件的结合，得到一个主题很高的限量版主机。......

装饰和几种图案的区别

装饰者和代理在结构和行为上与责任链模型相似现在我们来总结一下它们之间的区别

装饰模式与代理模式

装饰模式是代理模式的一个特殊应用。

装饰者模式强调自身功能的扩展。

代理模式强调对代理过程的控制。

装饰者VS责任链模式

在行为上，装饰者和责任链是多个单元的组合来完成逻辑处理，但装饰者注意的是给某个东西添加扩展，最终会得到一个产品责任链强调的是某个过程的逐步完成，更像是一个任务的链表，而不像装饰者模式，责任链可以随时终止

比如OA系统中请假审批的场景，假设员工请假需要班组长，总监，经理审批在这种情况下，如果你使用装饰者模式，无论你的休假在前一个环节是被批准还是被拒绝，整个链条都不会被打断最后，我们将从申请的三级审批者那里获得所有反馈

在责任链模型中，在每个阶段，每个审批人都有权批准或拒绝如果请求在任何级别被拒绝，整个流程将结束，并且该请求不会继续流向下一级别的审批者

所以看到这里，你是不是觉得Web框架的中间件之类的东西应该用责任链或者装饰器来实现。

摘要

装饰模式有很多优点它是继承的有力补充，比继承更灵活在不改变原有对象的情况下，它可以动态地将功能扩展到一个对象，即插即用通过使用不同的装饰类以及这些装饰类的排列组合，可以达到不同的效果，完全遵循编程的开闭原则

但是使用decorator肯定会给程序带来更高的复杂度和更低的可读性，子类集成的代码结构会更加直白易懂而且decorator虽然符合开闭原则，但是会给程序带来更多的类，动态装饰在多层装饰中会更复杂

因此，一般来说，在使用装饰模式时，两害相权取其轻为了不频繁修改已经形成的子类，引入了更多的装饰类

在应用的时候，一定要记住，装饰器是用来增强某个东西的，而千万不要用装饰器来实现这个东西本身的主要逻辑。