QGraphicsView 和装饰器模式答案

【问题标题】：QGraphicsView and the decorator patternQGraphicsView 和装饰器模式
【发布时间】：2014-03-13 13:01:32
【问题描述】：

问题适用于qt库的QGraphicsView类。然而，这个问题更普遍。所以，如果我没有遗漏qt中的任何特殊机制，大概可以在不知道qt的情况下讨论。

我正在继承 QGraphicsView 以添加一些我需要的功能。例如。我有一个ScalableView、PannableView 和LabeledView 来添加独立的功能。

我现在使用的子类化在以下意义上是线性的： ScalableView 派生自 QGraphics 视图。 PannableView 派生自 ScalableView 视图。 LabeledView 派生自 PannableView 视图。

由于这些功能是独立的，因此存在设计缺陷。应用 装饰器模式 来解决这个问题似乎适合我。问题是，QGraphicsView 不是接口，也不存在像 QAbstractGraphicsView 这样的接口类。所以，对我来说，不清楚如何实现这种模式。

另一个想法是使用模板。所以我可以从模板T 中导出每个视图。然后，我可以像 ScalableView<PannableView<LabeledView>>> 一样进行 insantiations。

您有什么更好的解决方案吗？在这种情况下，我更喜欢一种实现装饰器模式的方法，因为我想避免使用许多会增加编译时间的模板类。

【问题讨论】：

ScalableView 和 PannableView 为 QGraphicsView 添加了什么，而 QGraphicsView 类本身尚不可用？如果您只是删除功能，那是什么原因呢？
不是删除，而是添加功能。它使用鼠标滚轮使视图可缩放，并提供适合视图的功能。 PannableView 提供使用鼠标左键平移。
为什么不只从QGraphicsView继承一次，你需要不同功能的不同视图吗？
是的，这是主要原因。
@DrD 我看到的问题如下。为了应用装饰器模式，我将引入一个类 DecoratorView。这将从 QGraphicsView 派生，并且必须聚合一个 QGraphicsView。这可以通过接口实现。但是对于一个非抽象类，我最终会得到两个不同的 QGraphicsView 实例。

【解决方案1】：

Qt 风格的一个简单解决方案是创建一个派生自QGraphicsView 的类，并且只具有控制其行为的标志（无论它是可扩展的、可平移的、标记的等）。这些行为的实现仍将被拆分为方法，所以它是不像看起来那么单一。

装饰器模式当然可以通过定义一个中间（shim）接口来轻松实现。 QGraphicsView 不需要实现该接口 - 该接口仅供装饰器使用。

深度继承的问题在于无法精细控制行为的交互。您拥有的唯一控制是事件处理的顺序。这可能恰好就足够了，但它让我有些担心。没有修饰的装饰器模式也存在这个问题。

【讨论】：

谢谢，这是一个不错的选择。但是，正如您所提到的，缺点是这种方法的整体性。在我看来，我想添加的功能对于单一方法来说太复杂了。
@SebastianK 我没有说将其拆分为单个方法，只是将其拆分为一般方法。然后你会注意到它们是如何通过一个通用的 shim 接口暴露出来的，这直接导致了装饰器模式。

【解决方案2】：

在不了解完整设计的情况下，这可能有效，也可能无效，但也许会有所帮助。

一种可能的方法是封装 QGraphicsView 并创建提供您需要的不同功能的委托对象。然后，代表将负责为图形视图提供接口并转发消息。

这意味着为不同类型的功能创建不同的委托；一个 ScalableDelegate、一个 PannableDelegate 和一个 LabeledDelegate。

由于代理是独立的对象而不是从 QGraphicsView 继承的，因此您可以通过在图形视图上安装事件过滤器来获得很多功能。

然后，它们不是与您的 GraphicsView 交互的对象，而是通过相关委托进行通信。

如果这限制性太强，您可能需要从 QGraphicsView 继承以创建具有所需功能的视图，然后使用委托来根据需要公开所需的功能。

【讨论】：