转载

聊聊设计模式(4):装饰模式

Decorator Pattern,中文名为装饰者模式,这个模式思想很简单,但是特别容易把代码搞复杂,它包含四个重要角色:

  • Component , 抽象构件
  • ConcreteComponent , 具体构件
  • Decorator , 抽象装饰类
  • ConcreteDecorator , 具体装饰类

聊聊设计模式(4):装饰模式

这几个角色很容易把人搞懵,所以在使用这个模式之前要彻底理解它。ECMAScript 2017 中增加了修饰器,它从语法层面帮掩盖了 Decorator 装饰类和 Component 构件,极大程度方便了我们理解装饰器:

function activate(target){
 target.barkable = true;
 target.runnable = true;
}

@activate
class EDog{}

console.log(EDog.barkable, EDog.runnable); // true true

上面的代码很简单, activate 是一个开关装饰类,通过它激活了 EDog —— 不会跑、不会叫的电子狗,让它具备了 barkrun 能力。

场景复现

过年回来后业务压力不大,小苏让小喜抽空做一个代码发布平台,帮助团队迁移代码发布平台,之前的前端静态代码是通过 SVN 管理和发布的,现在需要迁移到 Git 上去,小苏说这是个重任。小喜暗自欣喜,这 TM 也太简单了。

使用开源的 gitlab 搭建了一个代码管理平台,然后在 gitlab 上添加了钩子,每次有代码推送时,向小喜的代码平台发送一个请求,小喜便直接执行 publish 操作:

class CodePlatform{
 publish(gitInfo) {
 this.scpCodeFromGitlabToOnline();
 }
 // 直接将 gitlab 代码直接复制到线上机器
 scpCodeFromGitlabToOnline() {
 // ...
 }
}

不久之后代码的构建从线下迁移到了线上,要求代码发布时先使用构建服务器处理,于是小喜给 CodePlatform 增加了一项功能:

class CodePlatform{
 publish() {
 this.transferCodeToBuilderServer(() => {
 this.scpCodeFromGitlabToOnline();
 });
 }
 scpCodeFromGitlabToOnline() {}
 // 将代码扔到构建服务器
 transferCodeToBuilderServer() {}
}

随着团队工程化程度越来越高,很多线下操作流程渐渐搬移到了线上进行云处理,后续又增加了测试服务器、日志服务器、安全监测服务器等,结果小喜的代码变成了这样:

class CodePlatform{
 publish() {
 // publish 的逻辑越来越重
 }
 scpCodeFromGitlabToOnline() {}
 transferCodeToBuilderServer() {}
 transferCodeToLogServer() {}
 transferCodeToSecureServer() {}
 transferCodeToTestServer() {}
}

小喜怎么也没想到,发布一个仓库在 CodePlatform 需要走这么多流程,这个类的职责越来越多,代码体积也越来越庞大,此时的小喜有点苦恼。

有一次,小喜学习 ES7 相关知识,突然看到一个叫做 Decorator 的东西,想了想似乎可以在项目中用一下。这不用不知道,一用吓一跳,原来之前的代码还可以这样架构:

// 为所有的服务添加日志服务
class LogService{}
const logger = new LogService();

@logger('build')
class BuildService{}

@logger('secure')
class SecureService{}

@logger('test')
class TestService{}

首先将服务抽离出来,然后:

const builder = new BuildService();
const securer = new SecureSevice();
const tester = new TestService();

@securer
@logger('CodePlatform')
class CodePlatform{
 @builder
 @tester
 publish() {}
}

让 CodePlatform 的代码先走一遍 securer ,在发布的时候走一遍 testerbuilder ,代码结构瞬间变得清晰了很多。

问题解析

我们经常在代码中干这件事情,尤其是业务代码。一些临时需求,为了图方便、图快,直接在原有的基础上增加几个方法,然后在执行入口位置添加补丁,时间长了之后,维护起来十分吃力,这也是为什么在业务交接时大家相互吐槽代码的主要原因之一。很多人拿到代码的第一感觉就是,写这代码的人是傻x,这代码得重构。

上面的问题在于 CodePlatform 承担了太多的职责,最后这个类变得特别繁忙,加上代码量多了之后,阅读难度提升了。事实上,测试、监控、日志、安全等都是发布之前对代码的流程化操作, CodePlatform 的核心功能是 发布代码 ,其他的操作都可以看做对待发布代码的装饰。

JS 中 Decorator 语法糖十分容易理解,它既可以装饰类也可以装饰类的成员方法。所以我就没把这个模式的具体实现写出来,感兴趣的可以到网上搜索下。

装饰模式

对类做职能补充有几种方式:

  • 继承,让继承类拥有父类的所有能力,并自我扩展
  • 关联,将两个功能集进行合并
  • 修改父类(基类),这是当然不推荐的方案

装饰模式,动态地给一个对象增加一些额外的职责 ( Responsibility ),就增加对象功能来说,装饰模式比生成子类实现更为灵活。

装饰者模式可以在运行时给对象动态地增加更多的职责,它属于通过建立关联方式来扩充对象的能力。从上面的例子中看得出来,CodePlatform 在装饰前后基本看不出差异,这就是这个模式的特点。

原文  http://www.barretlee.com/blog/2017/02/14/the-decorator-pattern-in-design-patterns/
正文到此结束
Loading...