通过级联删除进行撤消/重做

发布于 2024-07-11 06:59:44 字数 1648 浏览 7 评论 0原文

我正在尝试使用 命令模式 在我的应用程序中实现撤消/重做功能。 我面临一个问题。

为了说明这一点,我们假设您可以使用我的应用程序创建 2D 配置文件(任意数量)。

然后,您可以根据这些 2D 配置文件创建具有不同属性(名称、颜色、比例等)的 3D 零件。

+--------------+              +--------------+      +--------------+
| 2D profile A |              | 2D profile B |      | 2D profile C |
+--------------+              +--------------+      +--------------+
   |    |                            |
   |  +---------------+      +---------------+
   |  | 3D Part B     |      | 3D Part C     |
   |  | Colour : blue |      | Colour : grey |
   |  | Name : bibi   |      | Name : foo    |
   |  | Scale : 33%   |      | Scale : 100%  |
   |  +---------------+      +---------------+
+--------------+
| 3D Part A    |
| Colour : red |
| Name : aaa   |
| Scale : 50%  |
+--------------*

当删除配置文件时,基于此配置文件构建的所有 3D 零件也会自动删除(当要删除配置文件时,会通知 3D 零件管理器,并将删除过时的 3D 零件。视图也会收到更新图形用户界面)。

这就是我面临问题的地方:我正在编写用于删除 2D 配置文件的撤消/重做命令,它看起来像这样(伪代码):

virtual void redo()
{
    m_pProfileList.remove(m_pProfile); // This will automatically delete all 3D parts relying on the deleted 2D profile
}

virtual void undo()
{
   m_pProfileList.add(m_pProfile); // This will add the 2D profile, but the 3D Parts are lost
}

正如您在上面的代码中看到的,删除 2D 配置文件将根据删除的轮廓自动删除所有 3D 零件。

但是,在执行撤消操作时,将 2D 配置文件重新添加到列表中是不够的:3D 部分会丢失。

我应该怎么办 ? 撤消/重做命令是否应该负责删除 3D 零件(这实际上是由 3D 零件管理器完成的)? 这意味着撤消/重做命令还将负责通知视图更新 GUI。

或者撤消/重做命令是否应该创建将被删除的所有 3D 零件的内部副本,并让 3D 零件管理器删除 3D 零件?

或者还有其他更好的解决方案吗?

感谢您的帮助 !

I'm trying to implement an undo/redo feature into my application, using the Command Pattern. I'm facing a problem.

To illustrate it, let's imagine you can create with my application 2D profiles (as many as you want).

From these 2D profiles, you can then create a 3D part with different attributes (name, colour, scale, etc.).

+--------------+              +--------------+      +--------------+
| 2D profile A |              | 2D profile B |      | 2D profile C |
+--------------+              +--------------+      +--------------+
   |    |                            |
   |  +---------------+      +---------------+
   |  | 3D Part B     |      | 3D Part C     |
   |  | Colour : blue |      | Colour : grey |
   |  | Name : bibi   |      | Name : foo    |
   |  | Scale : 33%   |      | Scale : 100%  |
   |  +---------------+      +---------------+
+--------------+
| 3D Part A    |
| Colour : red |
| Name : aaa   |
| Scale : 50%  |
+--------------*

When a profile is deleted, all 3D parts which a built on this profile are automaticaly deleted too (when a profile is about to be deleted, a 3D part manager is notified and will delete the obsolete 3D parts. Views are also notified to update the GUI).

This is where I'm facing a problem : I'm writing the undo/redo command for deleting a 2D profile, which looks something like this (pseudo-code) :

virtual void redo()
{
    m_pProfileList.remove(m_pProfile); // This will automatically delete all 3D parts relying on the deleted 2D profile
}

virtual void undo()
{
   m_pProfileList.add(m_pProfile); // This will add the 2D profile, but the 3D Parts are lost
}

As you can see in the code above, removing the 2D profile will automatically delete all 3D parts relying on the removed profile.

But when doing undo, re-adding the 2D profile to the list is not enough : the 3D parts are lost.

What should I do ? Should the undo/redo command be responsible of taking care of the deletion of the 3D parts (which is something actually done by the 3d part manager) ? This would mean the undo/redo command would also be responsible to notify the views to update the GUI.

Or should the undo/redo command create an internal copy of all 3d parts which will be deleted and let the 3d part manager delete the 3D parts ?

Or is there another better solution ?

Thanks for your help !

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

知足的幸福 2024-07-18 06:59:44

您想要对此稍有变化:Memento 模式。 您可以存储完整对象树的快照,也可以仅存储每次更改时的所有差异。 有了这些连续的变化历史,您就可以根据您的喜好来回前进和后退,而不会丢失依赖的对象。

You want a slight variation on this: the Memento pattern. You store snapshots of either your complete object tree or just all the differences at each change. Armed with this successive history of changes, you can then go backwards and forward in through commands to your hearts content, without losing dependant objects.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文