我可能会在这里讨论讨论类型问题,所以如果问题不够具体,我会道歉。
我想知道我目前的应用程序设计是否本质上是弱/有缺陷的。我的背景是C,所以我没有充分利用聪明的c ++模式,我相信这一点。
我的应用程序类似于3D建模包,没有几何创建(例如使用现有模型设置动画)。用户导入几何体并可以在预先存在的几何体上设置各种参数,并且存在与整个系统相关的时间相关值。输出是一个文本文件,由另一个应用程序处理。
我正在使用QTreeview呈现QStandardItemModel。我只是在模型的项目中存储指向核心类的指针。它们具有每种类类型的特定UI,并且都来自公共基类。他们都有一个QWidget,这是他们的" mainwidget"
当用户点击树视图的一部分时,将检索存储的类,并在UI的窗格上显示其主要部件。所以 - 左边的树视图,右边的窗格显示当前项目的内容,以及显示几何图形的3D视图。
我的大多数数据都存储在类UI元素本身中;我没有一个存储任何内容的中央数据库,当它有时间保存项目时,我遍历树并让每个项目自己写入QSettings文件。这感觉很幼稚,但它确实有效,而相反的情况发生在项目负载上。项目类根据设置文件中的类型信息生成新类,然后他们自己从文件中读取内容。
类似地,在编写输出文件时,每个项目都知道如何编写自己并且这样做。如果其他类可以影响其他类的输出(例如,开始和结束时间),则更高级别的类处理子项,并将根据每个子项的顺序和持续时间设置开始和结束时间。
我应该在QStandardItemModel本身存储更多数据,还是定义我自己的模型?这听起来像是为未来的问题做好准备吗?
目前我已修改此系统几次以提供自定义应用程序,但我即将尝试使其更通用。我欢迎有关改进设计的建议。请放轻松!
答案 0 :(得分:1)
您应该尽量避免创建god objects。将您的任务和职责分成更小的块。如果需要,它使维护更容易,也更容易扩展。
通过更全面地使用Model-View-Controller pattern,您的具体用例会受益匪浅。
在您的设计中没有意义的是您的数据对象包含UI元素。由于右窗格中只能显示一个项目,这似乎是浪费资源。有一个对象然后传递给要显示的数据对象更有意义。
我建议您的计划如下:
QDataStream
或QTextStream
文档中显示的方法。QTreeView
和QStandardItemModel
作为Adaptor class。QTreeView
通知。然后,控制器将检索数据项并将其传递到右侧面板以便显示。此模式的另一个优点是您只需创建一个小部件即可在右侧面板中显示数据。如果更改了所选项目,则只需将其传递给已存在的视图类,并使其使用新选择的数据刷新其显示。如果选择了不同类别的数据对象并且需要以不同方式绘制其数据,则只需要销毁右侧面板视图窗口小部件。控制器类可以确定是否可以重用右侧面板视图窗口小部件,或者是否需要将其换出为其他窗口小部件。