摘要生成中...

AI 摘要

Hunyuan-lite

装饰器模式通过组合替代继承的方式在不改变原始类的情况下添加增强功能，主要解决继承关系过于复杂的问题。

登场角色：

Component（部件）：增加功能时的核心角色。Component 角色只是定义了被装饰物接口（API）。
ConcreteComponent（具体部件）：该角色是实现了 Component 角色所定义的接口（API）的具体被装饰物。
Decorator（装饰物）：该角色具有与 Component 角色相同的接口（API）。在它内部保存了被装饰对象——Component 角色。Decorator 角色知道自己要装饰的对象。
ConcreteDecorator（具体的装饰物)：该角色是具体的 Decorator 角色，它在实现方法时，会通过委托，调用 component，从而实现方法增强。

Main 中的嵌套装饰：

Component c = 
	new ConcreteDecorator1(
		new ConcreteDecorator2(
			new ConcreteDecorator3(
				new ConcreteComponent(); // 被装饰物
			)
		)
	)

优点	缺点
无需创建新子类即可扩展对象的行为。	在封装器栈中删除特定封装器比较困难。
可以在运行时添加或删除对象的功能。	实现行为不受装饰栈顺序影响的装饰比较困难。
可以用多个装饰封装对象来组合几种行为。	各层的初始化配置代码看上去可能会很糟糕。
单一职责原则。可以将实现了许多不同行为的一个大类拆分为多个较小的类。

拓展思路：

接口（API）的透明性：装饰边框与被装饰物具有一致性。Decorator 是被装饰物 Component 的子类就体现了它们的一致性，它们具有相同的接口（API）。即使被装饰物被装饰起来了，接口（API）也不会隐藏起来，依然可以调用，这就是接口的透明性。
在不改变被装饰物的前提下增加功能。
可以动态地添加功能。装饰器模式中使用委托，它使类之间形成了弱关联关系。因此，不用改变框架代码，就可以生成一个与其他对象具有不同关系的新对象。
只需要添加一些装饰物即可添加许多功能。这些功能可以自由组合。
缺点：导致增加许多很小的类

Java I/O 中的装饰者模式

Java IO 的类库十分庞大，有 40 多个类，负责 IO 数据的读取和写入。我们可以从以下角度将其划分为四类，具体如下：

抽象基类	字节流	字符流
输入流	`InputStream`	`Reader`
输出流	`OutputStream`	`Writer`

针对不同的读取和写入场景，Java IO 又在四个父类基础上，扩展了很多子类：

一个输入流的装饰器模式结构：

FilterInputStream 是一个抽象的装饰者，构造函数声明为 protected，表明用户不能直接构造该类的对象，只能构造该类的子类对象。对于一些不需要装饰的方法，如 read()，FilterInputStream 只是简单交由被装饰对象 InputStream 完成。

本文 PlantUML 存档

abstract class Component{
	{method} {abstract} method1
	{method} {abstract} method2
	{method} {abstract} method3
}

class ConcreteComponent{
	{method} method1
	{method} method2
	{method} method3
}

abstract class Decorator{
	component
}

class ConcreteDecorator{
	{method} method1
	{method} method2
	{method} method3
}

Component <|-- ConcreteComponent
Component <|- Decorator
Component -o Decorator
Decorator <|-- ConcreteDecorator