装饰器流是否也实现为流实例的适配器或其他一些设计模式？答案

【问题标题】：Are the decorator streams also implemented as adapters of stream instances or as some other design pattern?装饰器流是否也实现为流实例的适配器或其他一些设计模式？
【发布时间】：2017-05-25 14:11:13
【问题描述】：

简而言之，来自 C#：

流适配器被实现为流实例的适配器。

装饰器流是否也实现为流的适配器实例？他们实现了什么设计模式？
请注意，装饰器流是作为派生类实现的 System.Stream 或其派生类，而流适配器不是（但我猜是通过组合）。所以我想知道适配器是否模式可以通过组合还是继承来实现？
- 适配器是否总是根据组合而不是继承来实现（以便它们可以处理来自他们适应的那些）？
- 装饰器是否总是根据继承而不是组合来实现（因此它们总是可以以与他们装饰的那个）？

谢谢。

【问题讨论】：

标签： c# design-patterns

【解决方案1】：

适配器一般会改变接口，装饰器一般不会。

这就是为什么图表中“装饰器流”的使用者能够相互替换任何这些类的原因。无论是缓冲流还是加密流，代码都不会改变。

另一方面，Readers 和 Writer（您的 Stream Adapters）的消费者期望一个非常具体的接口，该接口是高度定制的，并且因适配器而异。一个返回 XML 节点，另一个可能是原始类型。它们不能相互交换。

（GoF 书籍“设计模式”中有一个“装饰器”模式）。

【讨论】：

谢谢。适配器是否总是根据组合而不是继承来实现（以便它们可以处理与其适应的输入不同类型的输入）？装饰器是否总是根据继承而不是组合来实现（以便它们始终可以以与它们装饰的方式相同的方式使用）？
从来没有这样的事情。对于您的具体问题，虽然您的“装饰器流”需要从一个共同的祖先继承或实现，但它们在包装“后备存储流”时肯定会使用组合。这就是为什么您看不到 GzipMemroyStream 类和 GzipFileStream 类或任何其他排列的原因。这会导致具体的类爆炸。