尝试学习一些新的设计模式时,遇到了以下问题。
假设我们具有以下界面:GUI_ITEM。
我们有一些实现它的类,例如:Canvas,TextView,ListView ..
目标是向这些类添加一些额外的行为,例如:
滚动条,标题,边框..
现在,由于我们要从同一接口向给定对象添加行为组合,
我猜测要使用的正确设计是装饰器。
这是UML
UML
(这是我正在学习的幻灯片演示)
因此用法将如下所示:
GUI_Item* gui = new Scrollbars(new Border(new Title(new Canvas() ) ) );
出现以下问题;
如果我要执行创建命令怎么办?
由于边框可以隐藏滚动条,或者我们添加了在另一个功能的同一位置创建的另一个功能,因此可以将其隐藏。
我想找出哪种设计模式是最好的解决方案,以及如何实现它,因为我想从客户身上消除这种责任。
我似乎无法在这里想到合适的设计模式?也许我应该将装饰器与其他解决方案结合起来?
我考虑过将成员添加到每个装饰器类中,以标记其层次结构(这样就无法一起创建具有相同层次结构的对象)
按显示顺序排列,但这似乎是一个不好的解决方案(因为我觉得它违反了OPEN / CLOSED原理)
谢谢!
答案 0 :(得分:1)
如果我要执行创建命令怎么办?
您可以通过指定要装饰的兼容子类在构造函数中指定它,但它确实笨拙,并且与装饰器的思想相反,在装饰器中,客户端可以轻松地装饰“可装饰”对象,并且可以在不中断的情况下添加/删除装饰器的实现代码。它呼应您引用的“打开/关闭”原理。
我考虑过将成员添加到每个装饰器类中,以标记其 层次结构(这样就无法创建具有相同层次结构的对象 一起)按显示顺序排列,但这似乎是一个不好的解决方案 (因为我感觉它违反了OPEN / CLOSED原理)
它将重复/分散许多装饰器类中的装饰规则,并且违反了OPEN / CLOSED原理:添加/删除/更新装饰器代码可能需要更改许多装饰器。
我认为使用基类来表示gui项目和特定种类的项目是有意义的,但是使用装饰器将无济于事,因为应该在一个地方收集并执行渲染逻辑,以使规则一致且可维护(一个类可以更改) )。
我认为这应该是您在其中添加组件的根GUI项目。
这样,当您执行RootUi.add(GuiItem)
或RootUi.addAll(GuiItem...)
时,所有规则都将应用于单个位置。
这种模式是中介者。
请注意,如果可以使事情变得更清楚,则中介程序可以将其逻辑划分为多个处理类。例如,一个BackgroundProcessing
类可以处理背景,一个ForegroundProcessing
前景,另一个可以覆盖,等等。
答案 1 :(得分:1)
我认为(正如您可能也在想的那样),Decorator不是您尝试执行的最有用的模式。特别是,在您的设计中,小部件层次结构只能是一条直线(每个小部件下方最多具有一个装饰器/子小部件),而大多数GUI更自然地适合于分支树结构,每个小部件都可以容纳(并作为其“父级”)任何数量的子小部件,这些子小部件表示要物理保留在小部件的几何边界内的其他对象。
您可能想看一下其他一些流行的GUI API,以了解它们的设计方式-特别是,我认为Qt具有pretty good design-基于QWidgets的程序的GUI由{ {3}},其z顺序由树的结构定义(子窗口小部件的像素在其父像素的“前方”渲染),并且每个窗口小部件的x / y / w / h布局/位置均位于其父级-小部件由单独的QWidgets对象管理。