前端必须掌握的设计模式——装饰器模式

简介: 装饰器模式是一种结构型设计模式,通过创建新类来包装原始对象,实现在不修改原有结构的前提下扩展新行为。其核心在于“组合”思想,使新功能可“即插即拔”。该模式具有解耦性、灵活性和动态性等特点,广泛应用于类的面向对象编程语言中,如JavaScript的注解和TypeScript的写法。示例中,通过装饰器模式为游戏角色动态添加装备,展示了其强大的扩展性和灵活性。

定义

       装饰器模式(Decorator Pattern)属于结构型设计模式。将新的行为以创建类的方式去对原始对象进行包装,在实现同一接口并且不修改原有结构的前提下,达到扩展新行为的目的。简而言之,装饰器模式的核心展现出一种组合的思想,希望一切新的行为都是“即插即拔”的状态。

       对于那些基于类的面向对象编程语言做开发时,装饰器模式也深深被成熟运用。装饰器模式同样也是JS的大势所趋,从NextJs语法大量使用的注解,再到TypeScript的写法,再到ECMA未来可能将装饰器模式纳入标准,无时无刻不体现出了AOP(面向切面编程)思想的伟大。

特点

  • 解耦性:装饰器模式作为结构型的设计模式,更加体现了组合优于继承的思想。新增功能在不修改原有代码的基础上保持了动态性,不影响原有代码,保证了代码的完整性。
  • 灵活性:装饰器模式可以达到“即插即拔”的状态,在面对大型的项目时能够更灵活去处理复杂业务。
  • 动态性:可以很方便去添加移除一些功能,还不需要修改原有代码。

场景

       适用于给对象附加能力时使用,如Vue的指令设计,就很好体现了装饰器模式的作用;Java的注解也是对某个类进行能力的扩充。

举例实现

       这里我们举个例子,有一款“一刀999”的类传奇游戏有一个装备系统,我们将其拆解一下,得到一个本体和无数的插件。如果我要给一个用户一把“屠龙刀”,我正常继承原始对象是可以的。但如果我的需求是:我要给“划雨悦潭之赋”这个游戏玩家一把“屠龙刀”,一双“黄金之翼”,一枚“麻痹戒指”,那么使用传统的继承就不合适了。

本体.png

       这种场景下,我们可以使用装饰器模式,利用组合的思想去设计代码,如下图所示。 首先我们定义一个IBody的接口。创建一个Body的本体类去实现IBody接口,创建一个基础的装饰器类Decorator也去实现IBody接口,然后每个具体的装备类再去继承基础装饰类。

ove(message atring) vold.png

       在客户端,我们创建一个人物本体对象,创建“翅膀”的对象将本体对象传入,此时本体对象去操作对应的获得装备逻辑;再创建“武器”的对象将得到的创建“翅膀”的对象传入以此类推,最后将得到的对象调用give方法给予特定的目标;就像“叠房子”一样一层一层落。

       在具体装饰类中,我们部分重写了give方法,在处理自己的逻辑之前先调用父类的give方法,形成一个链条。具体代码如下:

// 人物本体接口
interface IBody {
  give(roleName: string): void;
}
// 基础人物本体类
class Body implements IBody {
  private name: string;
  constructor(name: string) {
    this.name = name;
  }
  give(roleName: string): void {
    console.log(`给角色"${roleName}"提供道具`);
  }
}
// 基础装饰器 定义整个装饰器的结构 子类可以做扩展
class Decorator implements IBody {
  // 基础的装饰器类是不能够单独使用的
  private body: IBody;
  // 初始化时需传入一个IBody类型的实例
  constructor(body: IBody) {
    this.body = body;
  }
  give(roleName: string): void {
    this.body.give(roleName);
  }
}
// 具体装饰类 翅膀
class WingDecorator extends Decorator{
  private wingName: string;
  constructor(body: IBody, wingName: string) {
    super(body);
    this.wingName = wingName;
  }
  // 重写父类的give方法
  give(roleName: string): void {
    // 调用父类的give方法
    super.give(roleName);
    // 给人物赠送翅膀
    console.log(`系统赠送[翅膀]"${this.wingName}"给"${roleName}"`);
  }
}
// 具体装饰类 翅膀
class WeaponDecorator extends Decorator{
  private weaponName: string;
  constructor(body: IBody, weaponName: string) {
    super(body);
    this.weaponName = weaponName;
  }
  // 重写父类的give方法
  give(roleName: string): void {
    // 调用父类的give方法
    super.give(roleName);
    // 给人物赠送武器
    console.log(`系统赠送[武器]"${this.weaponName}"给"${roleName}"`);
  }
}
// 具体装饰类 戒指
class RingDecorator extends Decorator{
  private ringName: string;
  constructor(body: IBody, ringName: string) {
    super(body);
    this.ringName = ringName;
  }
  // 重写父类的give方法
  give(roleName: string): void {
    // 调用父类的give方法
    super.give(roleName);
    // 给人物赠送戒指
    console.log(`系统赠送[戒指]"${this.ringName}"给"${roleName}"`);
  }
}
const body = new Body('');
const wingBody = new WingDecorator(body, '黄金之翼');
const wingWeaponBody = new WeaponDecorator(wingBody, '屠龙刀');
const wingWeaponRingBody = new RingDecorator(wingWeaponBody, '麻痹戒指');
wingWeaponRingBody.give('划雨悦潭之赋');

最终运行代码,可以得到如下的结果。我只give了一次,为什么会有4条输出呢?

image.gif 给角色例爾悦 之就基供道具.png

       在每一个new之后都打印一下实例,可以看到最终到wingWeaponRingBody时,已经形成了“麻痹戒指-屠龙刀-黄金之翼-”的链条。当调用give方法时,先会调用父类的give方法,而父类的give方法执行的是this.body.give(),也就是说会一层一层执行下去,从而达到组合的效果;装饰器类作为工厂方法被调用,返回的是一个装饰器类。调用逻辑如下图。        

image.gif bsdr! winoecorator ( tosyt Boly ( nsse! ).vinghione 美金之黑,),.png

装饰器方式

       TS中的装饰器模式还。需要将具体的装饰器类改写成装饰器方法,用JS原型的特性形成原型链调用give方法;在调用时使用@符号,大大提高了客户端调用代码的便捷性。

// 人物身体接口
interface IBody {
  give(message: string): void;
}
// 基础人物身体类
class Body implements IBody {
  private name: string;
  constructor(name: string) {
    this.name = name;
  }
  give(roleName: string): void {
    console.log(`给角色"${roleName}"提供道具`);
  }
}
// 基础装饰器 定义整个装饰器的结构 子类可以做扩展
class Decorator implements IBody {
  // 基础的装饰器类是不能够单独使用的
  private body: IBody;
  // 初始化时需传入一个IBody类型的实例
  constructor(body: IBody) {
    this.body = body;
  }
  give(roleName: string): void {
    this.body.give(roleName);
  }
}
// TS装饰器的写法 翅膀
export function WingDecorator(wingName: string): ClassDecorator {
  return function(constructor: Function) {
    const send = constructor.prototype.give; // 先拿到原型上的give方法
    // 然后再扩展自己的逻辑
    constructor.prototype.give = function(roleName: string) {
      // 扩展之前先执行一遍give方法
      send.apply(this, arguments);
      // 扩展自己的逻辑
      console.log(`系统赠送[翅膀]"${wingName}"给"${roleName}"`);
    }
  };
}
// TS装饰器的写法 武器
export function WeaponDecorator(weaponName: string): ClassDecorator {
  return function(constructor: Function) {
    const send = constructor.prototype.give; // 先拿到原型上的give方法
    // 然后再扩展自己的逻辑
    constructor.prototype.give = function(roleName: string) {
      // 扩展之前先执行一遍give方法
      send.apply(this, arguments);
      // 扩展自己的逻辑
      console.log(`系统赠送[武器]"${weaponName}"给"${roleName}"`);
    }
  };
}
// TS装饰器的写法 戒指
export function RingDecorator(ringName: string): ClassDecorator {
  return function(constructor: Function) {
    const send = constructor.prototype.give; // 先拿到原型上的give方法
    // 然后再扩展自己的逻辑
    constructor.prototype.give = function(roleName: string) {
      // 扩展之前先执行一遍give方法
      send.apply(this, arguments);
      // 扩展自己的逻辑
      console.log(`系统赠送[戒指]"${ringName}"给"${roleName}"`);
    }
  };
}
// 客户端使用
@WingDecorator('黄金之翼')
@WeaponDecorator('屠龙刀')
@RingDecorator('麻痹戒指')
class Client extends Body{
  constructor(name: string) {
    super(name);
  }
}
const client = new Client('');
client.give('划雨悦潭之赋');

TS装饰器不生效问题

       TS中装饰器还是实验性语法,所以直接使用@符号是不生效的。需要在配置文件中,显式将experimentalDecorators设为true。

{
    "compilerOptions": {
        "experimentalDecorators": true,
    }
}

image.gif 总结

       装饰器模式很好诠释了“组合”的思想,能够保证设计原则的同时也大大提高了客户端使用的便捷性,但也不要过度装饰和包装,可能导致太多层反而增加代码复杂度。前端必须掌握的设计模式系列持续更新,如果对您有帮助希望多多点赞哦!

image.gif temp1.png

相关文章
|
7天前
|
设计模式 前端开发 搜索推荐
前端必须掌握的设计模式——模板模式
模板模式(Template Pattern)是一种行为型设计模式,父类定义固定流程和步骤顺序,子类通过继承并重写特定方法实现具体步骤。适用于具有固定结构或流程的场景,如组装汽车、包装礼物等。举例来说,公司年会节目征集时,蜘蛛侠定义了歌曲的四个步骤:前奏、主歌、副歌、结尾。金刚狼和绿巨人根据此模板设计各自的表演内容。通过抽象类定义通用逻辑,子类实现个性化行为,从而减少重复代码。模板模式还支持钩子方法,允许跳过某些步骤,增加灵活性。
|
13天前
|
设计模式 存储 供应链
前端必须掌握的设计模式——观察者模式
观察者模式(Observer Pattern)是一种行为型设计模式,实现了一种订阅机制。它包含两个角色:**观察者**(订阅消息、接收通知并执行操作)和**被观察者**(维护观察者列表、发送通知)。两者通过一对多的关系实现解耦,当被观察者状态改变时,会通知所有订阅的观察者。例如,商店老板作为被观察者,记录客户的需求并在商品到货时通知他们。前端应用中,如DOM事件注册、MutationObserver等也体现了这一模式。
|
26天前
|
设计模式 前端开发 调度
前端必须掌握的设计模式——工厂模式
工厂模式是一种创建型设计模式,通过工厂媒介提供统一接口来创建对象,客户端只需告知创建需求,具体逻辑由工厂处理。工厂模式分为简单工厂、标准工厂和抽象工厂,分别适用于不同场景下的对象创建需求。简单工厂利用静态方法创建对象,标准工厂通过具体工厂类减少耦合,抽象工厂则用于创建一系列相关或依赖对象的家族。
|
6天前
|
设计模式 存储 缓存
前端必须掌握的设计模式——策略模式
策略模式(Strategy Pattern)是一种行为型设计模式,旨在将多分支复杂逻辑解耦。每个分支类只关心自身实现,无需处理策略切换。它避免了大量if-else或switch-case代码,符合开闭原则。常见应用场景包括表单验证、风格切换和缓存调度等。通过定义接口和上下文类,策略模式实现了灵活的逻辑分离与扩展。例如,在国际化需求中,可根据语言切换不同的词条包,使代码更加简洁优雅。总结来说,策略模式简化了多条件判断,提升了代码的可维护性和扩展性。
|
11天前
|
设计模式 消息中间件 供应链
前端必须掌握的设计模式——发布订阅模式
发布订阅模式(Publish-Subscribe Pattern)是一种设计模式,类似于观察者模式,但通过引入第三方中介实现发布者和订阅者的解耦。发布者不再直接通知订阅者,而是将消息发送给中介,由中介负责分发给订阅者。这种方式提高了异步支持和安全性,适合复杂、高并发场景,如消息队列和流处理系统。代码实现中,通过定义发布者、订阅者和中介接口,确保消息的正确传递。此模式在前端开发中广泛应用,例如Vue的数据双向绑定。
|
17天前
|
设计模式 前端开发 数据安全/隐私保护
前端必须掌握的设计模式——代理模式
代理模式(Proxy Pattern)是一种结构型设计模式,通过引入“替身”对象来间接访问真实对象,从而解耦并提升性能和安全性。例如,知名艺人复出后,经纪人作为代理筛选商单,确保只处理符合团队利益的请求。代码实现中,定义接口`IService`,艺人和经纪人都实现该接口,经纪人在访问时进行过滤和转发。代理模式常用于权限控制、性能优化等场景,如前端中的Tree-shaking和ES6的Proxy构造方法。
前端必须掌握的设计模式——代理模式
|
28天前
|
设计模式 存储 前端开发
前端必须掌握的设计模式——单例模式
单例模式是一种简单的创建型设计模式,确保一个类只有一个实例,并提供一个全局访问点。适用于窗口对象、登录弹窗等场景,优点包括易于维护、访问和低消耗,但也有安全隐患、可能形成巨石对象及扩展性差等缺点。文中展示了JavaScript和TypeScript的实现方法。
|
20天前
|
设计模式 JSON 前端开发
前端必须掌握的设计模式——适配器模式
适配器模式是一种结构型设计模式,用于使接口不兼容的对象能够相互合作。通过在客户端和系统之间引入一个“中间层”适配器,将不同类型的输入数据转换为系统能处理的标准格式,减轻系统的负担,提高扩展性和可维护性。例如,MacBook的扩展坞将多种接口(如HDMI、USB)转换为Type-C接口,实现多接口兼容。
|
3月前
|
存储 人工智能 前端开发
前端大模型应用笔记(三):Vue3+Antdv+transformers+本地模型实现浏览器端侧增强搜索
本文介绍了一个纯前端实现的增强列表搜索应用,通过使用Transformer模型,实现了更智能的搜索功能,如使用“番茄”可以搜索到“西红柿”。项目基于Vue3和Ant Design Vue,使用了Xenova的bge-base-zh-v1.5模型。文章详细介绍了从环境搭建、数据准备到具体实现的全过程,并展示了实际效果和待改进点。
223 14
|
3月前
|
JavaScript 前端开发 程序员
前端学习笔记——node.js
前端学习笔记——node.js
60 0