decorator模式的利弊是什么？
我正在读这篇文章：
http://www.codeproject.com/articles/479635/UnderstandPlusImplementingPlusDecoratorp
我正在考虑在一个学校项目中实施这种模式。这不是一个要求，所以我可以半屁股。但是，我只是认为这将是一个扩大我的知识和专长的好机会。
这是我的问题：这似乎不是一个好的模式，这是为什么：
每当“披萨店”在他们的菜单上添加了新的顶部....他们将不得不添加一个全新的类，重新编译他们的订购系统并重新分发？
我认为问题可能是所有的例子我谷歌必须处理的食物和浇头某种类型。
- 我只是为这个模式找到了错误的示例类型吗？
- 有哪些更好的示例可以实现此模式？
- 食品行业是不是其中之一，只是实施上的问题？
- 这是不是已经存在但几乎不在实际生产代码中使用的模式之一？
共有1个答案
实际上Decorator允许您在不重新编译源代码的情况下添加一些行为。您可以在pizza域中声明ipizza接口，并在应用程序中使用此抽象。然后您可以添加另一个程序集，如果ipizza修饰器，则该程序集将具有其他实现，并使用依赖项注入将那些实现注入到您的应用程序中。因此，您将不需要重新编译应用程序或域。
顺便说一句，添加新类比修改现有类更好。你总是可以打破一些在你修改之前工作的东西。因此引入了单一责任原则。
你的另一个问题：
- 不，您正在找到装饰器模式用法的好例子（特别是Head First一书中的例子）。还可以看看IO Stream类及其装饰器以获得灵感。
- 模式恰恰应该解决问题。如果您没有什么问题，那么这只是模式的错误用法。
- 模式并不拘泥于工业。他们坚持您的代码的问题（通常是关于代码重复的问题）
- 不，这是个好图案。再想想.NET中的流。是生产代码吗？
-
问题内容： 我想看一个例子： 什么时候合适 当这不合适时 是否有一段时间数据库的选择会与上述示例有所不同？ 问题答案： 这似乎是关于 代理 键的问题， 代理 键始终是自动递增的数字或GUID，因此是单列，而 自然 键则通常需要多个信息才能真正唯一。如果您能够拥有仅一列的自然键，那么无论如何，这一点显然是没有意义的。 有些人会坚持只使用其中之一。花足够的时间使用生产数据库，您将了解到没有任何上下文无
-
这个答案几乎描述了问题的前半部分。 上面写着： 看过“四人帮”的定义后，我不相信这有什么真正的区别。（为方便起见包括在内） 装饰器：允许对对象进行动态包装，以便修改它们现有的职责和行为 责任链：通过将接收对象链接在一起，使多个对象有机会处理请求 维基百科对它们做了一些补充，但有些是武断的。 > 装饰器通常作为链表实现。但我认为这太低了，不能被认为是模式的“一部分”。 责任链只处理数据，如果这是他们
-
我不喜欢这个模式的地方，就像我添加的链接的评论中提到的那样，一个topping不是一个pizza，所以为什么它要继承pizza类呢？ 我心目中的解决方案是在对象中使用对象数组，并使用该数组添加或删除披萨的浇头。 这种解决方案不是比使用decorator模式简单得多吗？为什么我们要考虑在这种情况下使用decorator模式呢？
-
问题内容： 我在写简单的太阳系模拟器。这是我的第一个libgdx项目。我在主菜单中使用舞台和演员，非常方便，尤其是触摸事件处理。但是…看这些例子，我发现没有人在实际的游戏逻辑中使用演员。如果我应该使用actor作为行星类的父母，或者只是写我自己的类，我会徘徊。行星将不可触摸，它们只能在帧之间移动，因此动作MoveBy的第三个参数必须是帧之间的时间。那就是缺点。使用Actor有哪些优点？ 问题答案：
-
本文向大家介绍rem的弊端是什么？相关面试题，主要包含被问及rem的弊端是什么？时的应答技巧和注意事项，需要的朋友参考一下 移动端用rem，但不能完全依赖rem，得看公司需求，若pc端和移动端都想一起做的话，那就全部都用rem，样式只用写一套。 如果仅仅只纯粹的做一个移动端，那么整体布局尽量用百分比，少用rem来定宽和定高。