问装饰图案问题
EN

Stack Overflow用户

提问于 2016-06-05 16:31:32

回答 4查看 1K关注 0票数 2

最近，我读到了关于装饰设计模式的文章，但是留下了一些我在网上找不到的未回答的问题。我不打算显示代码，因为我不想让这个问题变得比实际更复杂。我只举一个例子：

地铁商店：

组件--> SubSandwich

ConcreteComponent ->15 15cmSub，30 15cmSub

装饰器->成分

ConcreteDecorator ->白奶酪，黄奶酪，果酱，鸡肉。。

这就是地铁商店的工作方式。选择你的核心砂子大小，然后添加所有你喜欢的配料。但我还有一些问题：

如果成分组合无效怎么办？例如，地铁的政策说，不可能有两种奶酪在同一潜艇。现在，让我们假设有10000种可能的组合，而只有一个是无效的。这完全打破了装饰的模式吗？
如果有两种成分是依赖的。例如，如果你点了生菜，那么你需要一些其他种类的蔬菜来做一个“有效”的子菜。
什么时候使用装饰模式比使用成分为SubSandwich的ArrayList类更好呢？我知道这里的成分并没有增加行为，这使得地铁的例子不准确，但让我们假设它们确实如此。
为什么要扩展？为什么不使用接口呢？

发布于 2016-06-05 17:04:03

模式并不适用于每个用例。实际上，装饰器模式对于构建一个多组分结构并没有多大用处，因为它将所有的东西组合成一个只有一个接口的对象。只有在新的行为仅仅是“装饰”的情况下，这种做法才能奏效。一个很好的例子是Collections.synchronizedList(List list)，它通过包装一个synchronized块来“装饰”所有方法。您可能仍然可以在您描述的用例中使用一个装饰器，但是每个装饰步骤都必须检查它是否可以应用，如果不是，则抛出。老实说，我甚至不知道为什么这类例子如此受欢迎。我还没见过像这样的装饰图案。它不是为添加组件而制作的。
请参见1。这甚至可能是不可能的，因为生菜装饰师不能强制之后还有另一个装饰师。这显然不是一个好的模式使用。
在你更喜欢或者更好的情况下。就像三明治工厂。
因为这就是装潢师的诀窍。它装饰着现存事物的行为。您不想添加新的界面。一个有用的地方是当你是中间人的时候：例如，库A生成ListItem对象，您希望使用库B来显示它们。你既不能改变A生产什么，也不能改变B消耗它们的方式。但是，当您不喜欢A如何实现B用来显示的toString()方法时，您可以简单地包装一个新的toString()方法。它仍然是一个ListItem，所以B不会注意到，就像A也没有注意到任何东西一样。

票数 2

页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持

原文链接：

https://stackoverflow.com/questions/37644223

复制

相似问题

问装饰图案问题EN