我需要重新设计我的应用程序吗

Do I need to redesign my application?

本文关键字：我的应用程序更新时间：2023-10-16

我可能在这里遇到了一个讨论型问题，所以如果问题不够具体，我深表歉意。

我想知道我目前的应用程序设计是否天生薄弱/有缺陷。我的背景是C，所以我没有充分使用聪明的C++模式，我确信这一点。

我的应用程序类似于3D建模包，没有创建几何图形（例如使用现有模型设置动画）。用户导入几何图形，并可以在预先存在的几何图形上设置各种参数，并且存在与整个系统相关的时间相关值。输出是要由另一个应用程序处理的文本文件。

我正在使用QTreeview来呈现QStandardItemModel。我只是将指向核心类的指针存储在模型的项中。它们为每个类类型都有特定的UI，并且都是从一个公共基类派生而来的。他们都有一个QWidget，这是他们的"主窗口小部件"

当用户单击树视图的一部分时，将检索存储的类，并在UI上的窗格上显示其主窗口小部件。左侧的树视图，右侧的窗格显示当前项目的内容，以及显示几何图形的三维视图。

我的大部分数据都存储在类UI元素本身中；我没有一个存储任何内容的中央数据库，当需要保存项目时，我会遍历树，让每个项目都自己写入一个QSettings文件。这感觉很天真，但它确实有效，相反的情况发生在项目负载上。项目类根据设置文件中的类型信息生成新的类，然后它们自己读取文件中的内容。

类似地，在编写输出文件时，每个项目都知道如何编写自己并这样做。如果其他类会影响其他类的输出（例如，开始和结束时间），则更高级别的类会处理子项，并根据每个子项的顺序和持续时间设置开始和结束时刻。

我应该在QStandardItemModel本身中存储更多数据，还是定义自己的模型？这听起来像是我为未来的问题做好了准备吗？

目前，我已经对这个系统进行了几次修改，以提供定制的应用程序，但我即将尝试使其更通用。我欢迎为改进我的设计提出建议。请放松！

您应该尽量避免创建god对象。把你的任务和职责分成小块。它使它更容易维护，也更容易扩展，如果你需要的话

您的特定用例将从更完整地使用模型-视图-控制器模式中受益匪浅。

在您的设计中没有意义的是，您的数据对象包含一个UI元素。由于右窗格中只能显示一个项目，这似乎是在浪费资源。让一个对象传递一个要显示的数据对象更有意义。

我建议你的程序如下：

将数据拆分为仅具有报告和修改值功能的类。不应该知道如何显示数据或存储到文件中
创建一个单独的类来处理对文件的读取和写入。如果您的模型非常简单，您可以使用QDataStream或QTextStream文档中所示的方法，只使用单个函数即可完成此操作
使用QTreeView和QStandardItemModel作为数据对象和左面板之间的Adaptor类
创建一个控制器类，如果数据需要显示在右侧面板中，QTreeView会通知该类。然后，控制器将检索数据项并将其传递到右侧面板以便显示
右边的面板应该像另一个View类一样，只负责以图形方式显示从控制器类传入的数据

这样做的一个优点是，如果有不同类别的数据在右侧面板中以不同的方式显示，则控制器可以检查所选数据项，确定类别是什么，创建一个视图小部件放在右侧面板，然后将数据传递给它显示。就可扩展性而言，这种模式是开放式的，因为如果需要新的显示器，您不需要更改数据类，只需要创建一个新的右侧面板小部件，然后教控制器类如何确定何时应该使用新视图。

这种模式的另一个优点是，您只需要创建一个小部件就可以在右侧面板中显示数据。如果更改所选项目，只需将其传递给已存在的视图类，并使用新选择的数据刷新其显示。如果选择了不同类别的数据对象，并且需要以不同的方式绘制其数据，则只需要分发右侧面板视图小部件。控制器类可以确定是否可以重用右面板视图小部件，或者是否需要将其换成不同的小部件。