【问题标题】:object oriented design question for gui applicationgui应用程序的面向对象设计问题
【发布时间】:2011-04-19 19:35:17
【问题描述】:

伙计们,我正在为一个应用程序编写一个 GUI,一个用于插入 cd 的 cd 容器,目前我不是很清楚,我想我需要一些帮助来澄清我对面向对象设计的理解。

所以,首先,我使用观察者模式来构建抽象模型和视图类以及具体模型(cd 容器)和具体视图(cd 容器视图)。然后我开始使用 wxwidget 框架为 cd 容器和其他 gui 控件 MainFrame(来自 wxFrame)等设计和图形外观或布局(CDContainerWidget,来自 wxPanel)等。

所以现在我有三个类:CDContainerModel(cd 容器)、CDContainerView(观察者模式类)和CDContainerWidget(gui 控件)。 然后我变得不太清楚我应该如何处理CDContainerViewCDContainerWidget

我认为CDContainerWidget 和CDContainerView 都需要CDContainerModel。我想了四种方法,但不知道哪一种合适:

1)。将 CDContainerWidget 作为成员变量关联到 CDContainerView 中,然后将 CDContainerView 作为成员变量放入 Main Frame。

class CDContainerView:
  def __init__:
     self.gui=CDContainerWidget

class MainFrame:
  def __init__:
     CDContainerView

2)。 CDContainerView 子类 CDContainerWidget:

class CDContainerView(CDContainerWidget):

class MainFrame:

   def __init__:

     CDContainerView

3)。 CDContainerWidget 子类 CDContainerView:

class CDContainerWidget(CDContainerView):

class MainFrame:
  def __init__:
     CDContainerWidget

4)。而不是使用 CDContainerWidget 和 CDContainerView,只使用一个类 CDContainerBig,它是抽象类 View 和 wxPanel 的子类

class CDContainerBig(View, wxPanel)

我的问题是什么是正确的解决方案?我已经阅读了 MVC 模式的 wiki 页面,但我并不真正理解它的描述,也不知道如何将它应用于我的问题。

好吧,我添加了一些额外的 cmets。最初,当我开始设计编程时,我没有多想,只是选择了,2)方法。但现在,我认为 3) 很好。因为将小部件放入小部件(CDContainerWidget 放入 MainFrame)是合理的。但我不太确定。此外,对于观察者模式,这三个类似乎是扭曲和尴尬的。有时,在我看来,这 4 个可能是相同的,只是谁包括谁,或者谁向谁发送消息。好吧,我想我真的需要澄清这一点。

另外,我赞成 3) 因为一个实用的观点。CDContainerWidget 实际上包含几个子小部件组件(按钮、输入框等),如果我们通过子组件小部件设置新值之类的东西进行更改,那么对于1)、我们需要CDContainerWidget能够感知CDContainerView,让CDContainerView通知其他视图。对于 2) 更糟糕的是,CDContainerWidget 必须知道它的子 CDContainerView。 3)CDContainerWidget本身就是CDContainerView,所以比较合理。 4)很好,很容易但没有逻辑分离。这是我自己的想法,不知道对不对。

谢谢!!

【问题讨论】:

  • 永远不要评论你自己的问题。绝不。请更新您的问题以完成。然后,更新后,请删除混乱的cmets。永远不要评论你自己的问题。

标签: python user-interface design-patterns oop wxwidgets


【解决方案1】:

让您更容易摆脱类之间耦合的方法是使用 Spiff Signal 或其他可用的信号/插槽模块之一实现信号插槽模式。

通过解耦通信逻辑,您可以完全摆脱模块直接对话的需要,而是使用带有回调的消息传递。

【讨论】:

    【解决方案2】:

    选项 1 似乎最合适。一般来说,您应该避免继承,除非模式需要它,或者有其他令人信服的理由来使用它。过度使用继承会使你的代码比它必须的更紧密地集成。

    【讨论】:

    • 您好,p-static,谢谢您的回答。您能否更详细地说明为什么 1)最合适。您所说的只是“委托比继承更好”,仅此而已,这是一般的设计规则,但并非针对我的问题。老实说,我不是那么相信。
    • 嗯,根据我的经验,您不希望在程序的任何其他不需要它的部分(如 View 类)中依赖 GUI 代码 - 我已经这样做了做了几个项目,没多久就后悔了。这样就消除了 2) 和 4)。 3) 实际上看起来确实是一个合理的解决方案;我唯一的问题是我对继承的偏见。 :)
    • (对你所说的一切+1)。 “对继承的偏见”总是比将继承无处不在的非理性愿望要好。
    猜你喜欢
    • 2013-09-05
    • 2010-12-27
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2016-06-23
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多