在尝试学习一些新的设计模式时，我遇到了以下问题
假设我们有以下界面：GUI_ITEM
我们有一些实现它的类，如：Canvas、TextView、ListView
目标是为这些类添加一些额外的行为，例如：
滚动条、标题、边框。。
现在，由于我们希望将行为的组合添加到来自同一接口的给定对象，我猜应该使用的正确设计是装饰师
这是UML
UML
(这是我正在学习的幻灯片)
因此使用情况如下：
GUI_Item* gui = new Scrollbars(new Border(new Title(new Canvas() ) ) );
出现了以下问题
如果我想强制执行创建顺序，该怎么办
由于边框可以隐藏滚动条，或者我们添加了另一个在另一个功能的同一位置创建的功能，因此可以隐藏它。
我正试图弄清楚哪种设计模式将是最好的解决方案，以及如何实现它，因为我想从客户那里消除这一责任。
我似乎想不出一个合适的设计模式？也许我应该把装饰器和另一个解决方案结合起来
我曾考虑为每个标记其层次结构的decorator类添加一个成员(这样就不能一起创建具有相同层次结构的对象)在显示顺序中，但这似乎是一个糟糕的解决方案(因为我觉得它违反了打开/关闭原则)
谢谢！
我认为(正如你可能也在想的那样)Decorator并不是你想要做的最有用的模式。特别是，在你的设计中，小部件层次结构似乎只能是一条直线(每个小部件下面最多有一个Decorator/子小部件)，而大多数GUI更自然地适合分支树结构，其中每个小部件可以容纳(并充当)任意数量的子小部件，这些子小部件表示要物理地保持在小部件的几何边界内的其他对象。
你可能想看看其他一些流行的GUI API，看看它们是如何设计的——特别是，我认为Qt有一个非常好的设计——一个基于QWidget的程序的GUI由一棵QWidget树组成，z顺序由树的结构定义(子窗口小部件的像素呈现在"父窗口小部件像素的前面")，并且每个小部件在其父小部件内的x/y/w/h布局/定位由单独的QLayout对象管理。
如果我想强制执行创建顺序怎么办？
您可以通过指定要装饰的兼容子类来在构造函数中指定它，但这确实很笨拙，并且违背了装饰器的想法，在装饰器中，客户端可以轻松地装饰"可装饰"对象，并且可以在不破坏代码的情况下添加/删除装饰器的实现。这与您引用的"打开/关闭"原则相呼应。
我考虑为每个装饰器类添加一个成员，标记其层次结构(这样就无法创建具有相同层次结构的对象一起)，但这似乎是一个糟糕的解决方案(因为我觉得这违反了打开/关闭的原则)
它将在许多decorator类中重复/分散装饰规则，这违反了OPEN/CLOSED原则：添加/删除/更新装饰器代码可能需要在许多decurator中进行更改
我认为有一个基类来表示gui项和特定类型的项是有意义的，但使用decorator将没有帮助，因为渲染逻辑应该在一个地方收集和执行，以使规则一致和可维护(一个类需要更改)
我认为它应该是一个根gui项，您可以在其中添加组件。
这样，当您执行RootUi.add(GuiItem)或RootUi.addAll(GuiItem...)时，所有规则都将应用于一个位置
此模式是中介。请注意，中介可以将其逻辑划分为多个处理类，如果它能使事情变得更清楚的话。例如，BackgroundProcessing类可以处理背景，ForegroundProcessing类可以处理前景，另一个类可以处理覆盖，等等。。。