装饰模式(Decorator Pattern)

简介: 装饰模式是一种结构型设计模式,允许在不修改原有对象的情况下动态添加功能。它通过装饰类层层叠加实现功能扩展,适用于需要在运行时动态添加、修改或移除对象行为的场景。装饰模式的核心角色包括抽象组件、具体组件、抽象装饰和具体装饰。该模式的优点在于动态扩展功能、避免类爆炸和遵守开放-封闭原则,但可能会导致对象数量增加和调试困难。常见使用场景包括图形系统中的动态效果和输入流的功能扩展。

装饰模式(Decorator Pattern)详解

定义

装饰模式是一种结构型设计模式,允许动态地向对象添加新功能,而不会影响其他对象。装饰模式通过使用一系列装饰类,将额外的行为或责任以层叠的方式附加到对象上。


核心概念

角色组成

  1. 抽象组件(Component)
    定义对象可以动态添加行为的接口。
  2. 具体组件(Concrete Component)
    实现抽象组件接口的基本对象,可被装饰类增强功能。
  3. 抽象装饰(Decorator)
    持有一个抽象组件的引用,并定义一个与抽象组件一致的接口。
  4. 具体装饰(Concrete Decorator)
    扩展抽象装饰类,负责向组件添加额外功能。

装饰模式的类图


使用场景

  1. 功能扩展:需要在运行时动态地添加、修改或移除对象的行为。
  2. 避免继承膨胀:如果通过继承为对象添加功能会导致大量子类,装饰模式是更优的选择。
  3. 遵守开放-封闭原则:装饰类可以独立扩展,而不需要修改已有的类。

装饰模式的优缺点

优点

  1. 动态扩展功能:无需修改原始类,通过组合灵活添加功能。
  2. 遵守单一职责原则:每个装饰类负责特定功能,职责清晰。
  3. 避免类爆炸:减少子类数量,简化系统。

缺点

  1. 对象数量增加:多层装饰可能导致对象管理复杂化。
  2. 调试困难:由于装饰层叠的特性,可能难以跟踪功能的来源。

使用案例

案例 1:图形系统

  • 描述:在绘图应用中,可以为基本形状动态添加边框、阴影、颜色等功能。
  • 实现:基本形状为组件,装饰器实现不同的图形效果。

案例 2:输入流

  • 描述:在 Java 或 C# 中,输入流(如 FileStream)可以通过装饰器动态添加功能(如缓冲、加密)。
  • 实现:基础流是组件,加密流、缓冲流是装饰器。

C++ 实现

#include <iostream>
#include <memory>
using namespace std;

// 抽象组件
class Component {
public:
   virtual void operation() const = 0;
   virtual ~Component() = default;
};

// 具体组件
class ConcreteComponent : public Component {
public:
   void operation() const override {
       cout << "ConcreteComponent operation" << endl;
   }
};

// 抽象装饰
class Decorator : public Component {
protected:
   shared_ptr<Component> component;

public:
   explicit Decorator(shared_ptr<Component> comp) : component(move(comp)) {}
   void operation() const override {
       component->operation();
   }
};

// 具体装饰A
class ConcreteDecoratorA : public Decorator {
public:
   explicit ConcreteDecoratorA(shared_ptr<Component> comp) : Decorator(move(comp)) {}
   void operation() const override {
       Decorator::operation();
       addedBehavior();
   }

   void addedBehavior() const {
       cout << "ConcreteDecoratorA added behavior" << endl;
   }
};

// 具体装饰B
class ConcreteDecoratorB : public Decorator {
public:
   explicit ConcreteDecoratorB(shared_ptr<Component> comp) : Decorator(move(comp)) {}
   void operation() const override {
       Decorator::operation();
       addedBehavior();
   }

   void addedBehavior() const {
       cout << "ConcreteDecoratorB added behavior" << endl;
   }
};

// 客户端代码
int main() {
   shared_ptr<Component> component = make_shared<ConcreteComponent>();
   shared_ptr<Component> decoratorA = make_shared<ConcreteDecoratorA>(component);
   shared_ptr<Component> decoratorB = make_shared<ConcreteDecoratorB>(decoratorA);

   decoratorB->operation();

   return 0;
}


C# 实现

using System;

// 抽象组件
public abstract class Component {
   public abstract void Operation();
}

// 具体组件
public class ConcreteComponent : Component {
   public override void Operation() {
       Console.WriteLine("ConcreteComponent operation");
   }
}

// 抽象装饰
public abstract class Decorator : Component {
   protected Component component;

   public Decorator(Component component) {
       this.component = component;
   }

   public override void Operation() {
       component.Operation();
   }
}

// 具体装饰A
public class ConcreteDecoratorA : Decorator {
   public ConcreteDecoratorA(Component component) : base(component) { }

   public override void Operation() {
       base.Operation();
       AddedBehavior();
   }

   private void AddedBehavior() {
       Console.WriteLine("ConcreteDecoratorA added behavior");
   }
}

// 具体装饰B
public class ConcreteDecoratorB : Decorator {
   public ConcreteDecoratorB(Component component) : base(component) { }

   public override void Operation() {
       base.Operation();
       AddedBehavior();
   }

   private void AddedBehavior() {
       Console.WriteLine("ConcreteDecoratorB added behavior");
   }
}

// 客户端代码
class Program {
   static void Main() {
       Component component = new ConcreteComponent();
       Component decoratorA = new ConcreteDecoratorA(component);
       Component decoratorB = new ConcreteDecoratorB(decoratorA);

       decoratorB.Operation();
   }
}


知识点对比表

特性 装饰模式 继承 扩展方式
动态添加功能 √(动态) ×(静态,编译时) 动态添加功能
开放-封闭原则 遵守 可能违反(增加新功能需要修改子类) 遵守
对象数量 多层装饰增加对象数量 子类数量可能过多 对象数量
使用场景 功能动态变化时更适合 功能固定时更适合 使用场景

总结

  1. 动态扩展功能:装饰模式适合在运行时灵活地扩展对象行为。
  2. 避免类爆炸:通过装饰类组合,取代大量子类的设计。
  3. 推荐场景:需要动态变化的系统功能,且遵守开放-封闭原则的设计要求。
目录
相关文章
|
5天前
|
存储 运维 安全
云上金融量化策略回测方案与最佳实践
2024年11月29日,阿里云在上海举办金融量化策略回测Workshop,汇聚多位行业专家,围绕量化投资的最佳实践、数据隐私安全、量化策略回测方案等议题进行深入探讨。活动特别设计了动手实践环节,帮助参会者亲身体验阿里云产品功能,涵盖EHPC量化回测和Argo Workflows量化回测两大主题,旨在提升量化投研效率与安全性。
云上金融量化策略回测方案与最佳实践
|
7天前
|
人工智能 自然语言处理 前端开发
从0开始打造一款APP:前端+搭建本机服务,定制暖冬卫衣先到先得
通义灵码携手科技博主@玺哥超carry 打造全网第一个完整的、面向普通人的自然语言编程教程。完全使用 AI,再配合简单易懂的方法,只要你会打字,就能真正做出一个完整的应用。
7896 19
|
19天前
|
人工智能 自动驾驶 大数据
预告 | 阿里云邀您参加2024中国生成式AI大会上海站,马上报名
大会以“智能跃进 创造无限”为主题,设置主会场峰会、分会场研讨会及展览区,聚焦大模型、AI Infra等热点议题。阿里云智算集群产品解决方案负责人丛培岩将出席并发表《高性能智算集群设计思考与实践》主题演讲。观众报名现已开放。
|
11天前
|
自然语言处理 数据可视化 API
Qwen系列模型+GraphRAG/LightRAG/Kotaemon从0开始构建中医方剂大模型知识图谱问答
本文详细记录了作者在短时间内尝试构建中医药知识图谱的过程,涵盖了GraphRAG、LightRAG和Kotaemon三种图RAG架构的对比与应用。通过实际操作,作者不仅展示了如何利用这些工具构建知识图谱,还指出了每种工具的优势和局限性。尽管初步构建的知识图谱在数据处理、实体识别和关系抽取等方面存在不足,但为后续的优化和改进提供了宝贵的经验和方向。此外,文章强调了知识图谱构建不仅仅是技术问题,还需要深入整合领域知识和满足用户需求,体现了跨学科合作的重要性。
|
7天前
|
人工智能 容器
三句话开发一个刮刮乐小游戏!暖ta一整个冬天!
本文介绍了如何利用千问开发一款情侣刮刮乐小游戏,通过三步简单指令实现从单个功能到整体框架,再到多端优化的过程,旨在为生活增添乐趣,促进情感交流。在线体验地址已提供,鼓励读者动手尝试,探索编程与AI结合的无限可能。
三句话开发一个刮刮乐小游戏!暖ta一整个冬天!
|
1月前
|
存储 人工智能 弹性计算
阿里云弹性计算_加速计算专场精华概览 | 2024云栖大会回顾
2024年9月19-21日,2024云栖大会在杭州云栖小镇举行,阿里云智能集团资深技术专家、异构计算产品技术负责人王超等多位产品、技术专家,共同带来了题为《AI Infra的前沿技术与应用实践》的专场session。本次专场重点介绍了阿里云AI Infra 产品架构与技术能力,及用户如何使用阿里云灵骏产品进行AI大模型开发、训练和应用。围绕当下大模型训练和推理的技术难点,专家们分享了如何在阿里云上实现稳定、高效、经济的大模型训练,并通过多个客户案例展示了云上大模型训练的显著优势。
104579 10
|
7天前
|
消息中间件 人工智能 运维
12月更文特别场——寻找用云高手,分享云&AI实践
我们寻找你,用云高手,欢迎分享你的真知灼见!
617 39
|
4天前
|
弹性计算 运维 监控
阿里云云服务诊断工具:合作伙伴架构师的深度洞察与优化建议
作为阿里云的合作伙伴架构师,我深入体验了其云服务诊断工具,该工具通过实时监控与历史趋势分析,自动化检查并提供详细的诊断报告,极大提升了运维效率和系统稳定性,特别在处理ECS实例资源不可用等问题时表现突出。此外,它支持预防性维护,帮助识别潜在问题,减少业务中断。尽管如此,仍建议增强诊断效能、扩大云产品覆盖范围、提供自定义诊断选项、加强教育与培训资源、集成第三方工具,以进一步提升用户体验。
625 243
|
1天前
|
弹性计算 运维 监控
云服务测评 | 基于云服务诊断全方位监管云产品
本文介绍了阿里云的云服务诊断功能,包括健康状态和诊断两大核心功能。作者通过个人账号体验了该服务,指出其在监控云资源状态和快速排查异常方面的优势,同时也提出了一些改进建议,如增加告警配置入口和扩大诊断范围等。