Design patterns 装饰器比适配器更透明是什么意思？

我已经读到，装饰对客户机来说比适配器更透明，正是这种透明使嵌套装饰成为可能。在这种情况下，透明度究竟意味着什么

---

我知道这两种设计模式。所以您可以基于这个前提来回答问题。

对于客户端来说，使用装饰器和装饰对象（两者都有相同的接口）并没有区别。因此，decorator是透明的（即对客户端不可见）。Decorator也可以由其他Decorator进行装饰-这不会影响客户。客户仍然可以认为他正在处理装饰对象

很好的示例是

Streams

。您可以传递用任意数量的修饰符（压缩、加密、缓冲）修饰的流，但这些修饰符对于任何使用流的客户端都是不可见的

---

实际上我不明白为什么适配器可以被认为是透明的。客户机不应该知道适配器的类型，并且客户机不能将适配器视为适配器，因为它们有不同的接口。

回答装饰程序如何透明比为什么适配器偷偷摸摸或臃肿更简单。decorator倾向于更频繁地嵌套到批量功能中（这通常是正交的，例如，BufferedFileWriter添加了缓冲，这实际上不会改变类的基本操作及其包装：它将这些操作委派回原始操作）。通常，您可以很容易地看到装饰器在做什么，因为它在原始界面中隐藏了自己

适配器可以同样透明。我猜嵌套适配器更困难的原因是您正在谈论转换某些状态对象。然后你很快就会陷入所有的丑陋之中（MVC成长过程中发生的事情之一）。例如，我有一个旧的应用程序，它会给我一个风险评级，给出一系列的输入。有一个新的web界面想要使用它，但它需要另一种格式的数据。我们无法更改原始代码，因此我们引入了一个可转换的适配器。翻译什么？一般来说，一些州代表。因此，如果接口不同，它将接收输入并转换和重新调整它们，如果输出需要进一步按摩，同上。如果您将多个适配器分层，您将很快发现自己很难弄清楚是谁为最终呈现的对象贡献了什么（提供给服务或返回给消费者）

---

decorator通常不用于此类翻译作业，而是用于补充我们没有代码或新功能是正交的东西的功能，因此，我们允许用户使用或不使用一个或多个decorator。

decorator接受给定类型A的对象，并将其包装到相同类型A的对象中。客户端可以像使用实际对象一样使用装饰对象，因为它们具有相同的类型

适配器获取给定类型a的对象，并将其包装到另一类型B的对象中。然后，使用原始类型a的客户机必须调整为使用另一类型B

也就是说，如果我们使用适配器模式，那正是因为客户机需要一个类型为B的对象，而我们只有一个类型为a的对象。因此，我们将其包装到适配器中，使其成为类型为B的对象

---

这两种图案使用相同的原理（环绕），但用途不同。用于更改原始对象行为的装饰器。用于更改其类型的适配器。

透明度部分如何？这是我在第一部分中解释的：客户端使用装饰器的方式与使用装饰对象的方式相同，因为它们具有相同的类型。它对客户是透明的。您可以将字节写入BufferedOutputStream的方式与写入FileOutputStream的方式相同，因为它们都是OutputStreams。