侧边栏壁纸
博主头像
极客日记 博主等级

行动起来,活在当下

  • 累计撰写 93 篇文章
  • 累计创建 17 个标签
  • 累计收到 1 条评论

目 录CONTENT

文章目录

设计模式 - 装饰器模式

Jack.Jia
2024-01-05 / 0 评论 / 0 点赞 / 6 阅读 / 3602 字

装饰器模式

引言

在软件开发中,设计模式是解决常见问题的经过验证的解决方案。其中,装饰器模式是一种非常有用的结构型设计模式,它允许我们动态地添加行为和责任到对象上,而不需要修改其代码。

装饰器模式的核心思想是将一个对象包装在另一个同样实现了该对象接口的对象(即装饰器)中。装饰器接收所有来自客户端的请求,并将这些请求转发给被包装的对象。然后,装饰器可以添加一些附加行为,比如在请求处理之前或之后执行一些操作。

装饰器模式结构

装饰模式.png

举例说明

咖啡店

假设我们正在运营一个咖啡店,有各种各样的咖啡可供选择。然后我们可以加入各种配料,如牛奶、摩卡、豆浆等。每加入一种配料,都会增加咖啡的价格。

首先,我们定义一个基础咖啡类:

class Coffee
  def cost
    2.00
  end

  def description
    "Coffee"
  end
end

然后我们定义几个装饰器类来表示不同的配料:

class MilkDecorator
  def initialize(coffee)
    @coffee = coffee
  end

  def cost
    @coffee.cost + 0.4
  end

  def description
    @coffee.description + ", Milk"
  end
end

class MochaDecorator
  def initialize(coffee)
    @coffee = coffee
  end

  def cost
    @coffee.cost + 0.7
  end

  def description
    @coffee.description + ", Mocha"
  end
end

class SoyDecorator
  def initialize(coffee)
    @coffee = coffee
  end

  def cost
    @coffee.cost + 0.3
  end

  def description
    @coffee.description + ", Soy"
  end
end

现在,我们可以创建一个咖啡,并动态地添加配料:

coffee = Coffee.new
puts "#{coffee.description}: $#{coffee.cost}"

coffee = MilkDecorator.new(coffee)
puts "#{coffee.description}: $#{coffee.cost}"

coffee = MochaDecorator.new(coffee)
puts "#{coffee.description}: $#{coffee.cost}"

coffee = SoyDecorator.new(coffee)
puts "#{coffee.description}: $#{coffee.cost}"

这段代码会输出:

Coffee: $2.0
Coffee, Milk: $2.4
Coffee, Milk, Mocha: $3.1
Coffee, Milk, Mocha, Soy: $3.4 

这就是装饰器模式的基本用法。通过使用装饰器模式,我们可以动态地改变咖啡的成分和价格,而不需要修改咖啡类本身。

文件系统

装饰器模式也可以被用来处理文件系统中的读写操作。例如,我们可能需要在将数据写入文件之前对其进行压缩,或者在从文件读取数据后对其进行解压缩。

首先,我们创建一个简单的 FileWriter 类,它只是将数据写入一个文件:

class FileWriter
  def initialize(file_name)
    @file_name = file_name
  end

  def write(data)
    File.write(@file_name, data)
  end
end

然后我们可以创建一个 GzipWriterDecorator 类,它在将数据写入文件之前对其进行压缩:

require 'zlib'

class GzipWriterDecorator
  def initialize(real_writer)
    @real_writer = real_writer
  end

  def write(data)
    gz = Zlib::GzipWriter.new(@real_writer)
    gz.write(data)
    gz.close
  end
end

现在我们可以创建一个 FileWriter 对象,并使用 GzipWriterDecorator 添加压缩功能:

writer = FileWriter.new('test.txt')
writer = GzipWriterDecorator.new(writer)

# The data will be compressed before being written to the file.
writer.write('Hello, world!')

这样,我们就可以动态地为任何 FileWriter 对象添加压缩功能,而不需要修改 FileWriter 类本身。

日志记录

装饰器模式也可以用于日志记录。例如,我们可能有一个基本的日志记录器,它只是将消息输出到控制台。然后我们可能想要添加一些额外的功能,比如将日志消息写入到文件,或者在每条日志消息前面添加一个时间戳。

首先,我们创建一个简单的 Logger 类:

class Logger
  def log(message)
    puts message
  end
end

然后我们可以创建一些装饰器来添加额外的功能。例如,这是一个 FileLoggerDecorator,它将日志消息写入到一个文件:

class FileLoggerDecorator
  def initialize(real_logger, file_name)
    @real_logger = real_logger
    @file = File.open(file_name, 'a')
  end

  def log(message)
    @real_logger.log(message)
    @file.puts(message)
    @file.flush
  end
end

这是一个 TimestampLoggerDecorator,它在每条日志消息前面添加一个时间戳:

class TimestampLoggerDecorator
  def initialize(real_logger)
    @real_logger = real_logger
  end

  def log(message)
    @real_logger.log("#{Time.now}: #{message}")
  end
end

现在我们可以创建一个 Logger 对象,并使用这些装饰器来添加额外的功能:

logger = Logger.new
logger = FileLoggerDecorator.new(logger, 'log.txt')
logger = TimestampLoggerDecorator.new(logger)

# The message will be logged to the console and the file,
# and a timestamp will be added.
logger.log('Hello, world!')

装饰模式适合应用场景

  • 如果你希望在无需修改代码的情况下即可使用对象, 且希望在运行时为对象新增额外的行为, 可以使用装饰模式。

    装饰能将业务逻辑组织为层次结构, 你可为各层创建一个装饰, 在运行时将各种不同逻辑组合成对象。 由于这些对象都遵循通用接口, 客户端代码能以相同的方式使用这些对象。

  • 如果用继承来扩展对象行为的方案难以实现或者根本不可行, 你可以使用该模式。

    许多编程语言使用 final 最终关键字来限制对某个类的进一步扩展。 复用最终类已有行为的唯一方法是使用装饰模式: 用封装器对其进行封装。

装饰模式优缺点

优点

  • 你无需创建新子类即可扩展对象的行为。
  • 你可以在运行时添加或删除对象的功能。
  • 你可以用多个装饰封装对象来组合几种行为。
  • 单一职责原则。 你可以将实现了许多不同行为的一个大类拆分为多个较小的类。

缺点

  • 在封装器栈中删除特定封装器比较困难。
  • 实现行为不受装饰栈顺序影响的装饰比较困难。
  • 各层的初始化配置代码看上去可能会很糟糕。

与其他模式的关系

  • 适配器模式可以对已有对象的接口进行修改, 装饰模式则能在不改变对象接口的前提下强化对象功能。 此外, 装饰还支持递归组合, 适配器则无法实现。

  • 适配器能为被封装对象提供不同的接口, 代理模式能为对象提供相同的接口, 装饰则能为对象提供加强的接口。

  • 责任链模式装饰模式的类结构非常相似。 两者都依赖递归组合将需要执行的操作传递给一系列对象。 但是, 两者有几点重要的不同之处。

    责任链的管理者可以相互独立地执行一切操作, 还可以随时停止传递请求。 另一方面, 各种装饰可以在遵循基本接口的情况下扩展对象的行为。 此外, 装饰无法中断请求的传递。

  • 组合模式装饰的结构图很相似, 因为两者都依赖递归组合来组织无限数量的对象。

    装饰类似于组合, 但其只有一个子组件。 此外还有一个明显不同: 装饰为被封装对象添加了额外的职责, 组合仅对其子节点的结果进行了 “求和”。

    但是, 模式也可以相互合作: 你可以使用装饰来扩展组合树中特定对象的行为。

  • 大量使用组合装饰的设计通常可从对于原型模式的使用中获益。 你可以通过该模式来复制复杂结构, 而非从零开始重新构造。

  • 装饰可让你更改对象的外表, 策略模式则让你能够改变其本质。

  • 装饰代理有着相似的结构, 但是其意图却非常不同。 这两个模式的构建都基于组合原则, 也就是说一个对象应该将部分工作委派给另一个对象。 两者之间的不同之处在于代理通常自行管理其服务对象的生命周期, 而装饰的生成则总是由客户端进行控制。

总结

装饰器模式是一种非常实用和强大的设计模式。通过使用装饰器模式,我们可以动态地添加新的行为到对象上,而不需要修改这些对象的代码。这使得我们的代码更加灵活和可扩展。

在咖啡店的例子中,我们使用装饰器模式动态地添加了新的配料到咖啡上。在文件系统的例子中,我们使用装饰器模式在写入文件之前对数据进行了压缩。在日志记录的例子中,我们使用装饰器模式为日志消息添加了时间戳,并将它们写入到一个文件。

总的来说,无论你是在创建一个复杂的企业级应用,还是一个简单的脚本,装饰器模式都能帮助你保持代码的清晰和可维护,并使你的应用更容易适应变化。

0

评论区

🌟 遇见问题,不再有障碍!

你好,我是你的智能小助手。
点我,开启高效解答模式,让问题变成过去式。