保存/加载+撤消/重做的机制,最小样板

我想创建一个用户可以编辑图表的应用程序(例如),它将提供以下标准机制:保存,加载,撤消和重做.

一个简单的方法是为图表及其中的各种形状提供类,通过保存和加载方法实现序列化,并且所有编辑它们的方法都返回UndoableAction可以添加到UndoManager调用其perform方法和将它们添加到撤消堆栈.

上述简单方法的问题在于它需要很多容易出错的样板工作.

我知道工作的序列化(保存/加载)部分可以通过使用像Google的Protocol Buffers或Apache Thrift这样的东西来解决,它会为你生成样板序列化代码,但它不能解决undo + redo问题.我知道对于Objective C和Swift,Apple提供了解决序列化和撤销的核心数据,但我不熟悉C++的类似内容.

是否有一个很好的方法非容易错误解决save + load + undo + redo只有很少的样板？

上述简单方法的问题在于它需要很多容易出错的样板工作.

我不相信这是事实.您的方法听起来很合理,使用Modern C++功能和抽象,您可以为它实现安全和优雅的界面.

对于初学者来说,可以使用std::variant的金额类型为"可撤销的行为" -这会给你一个类型安全标签联合的每一个动作.(boost::variant如果您无法访问C++,请考虑使用或在Google上轻松找到的其他实现17).例:

namespace action
{
    // User dragged the shape to a separate position.
    struct move_shape
    {
        shape_id _id;
        offset _offset;
    };

    // User changed the color of a shape.
    struct change_shape_color
    {
        shape_id _id;
        color _previous;
        color _new;
    };

    // ...more actions...
}

using undoable_action = std::variant<
    action::move_shape,
    action::change_shape_color,
    // ...
>;

既然您有所有可能的"可撤消操作" 的总和类型,您可以使用模式匹配来定义撤消行为.我通过重载lambdas 写了两篇关于"模式匹配"的文章,你会发现它们很有趣:variant

"使用lambdas访问变体 - 第1部分"

"使用lambdas访问变体 - 第2部分"

以下是您的undo函数的外观示例:

void undo()
{
    auto action = undo_stack.pop_and_get();
    match(action, [&shapes](const move_shape& y)
                  {
                      // Revert shape movement.
                      shapes[y._id].move(-y._offset);
                  },
                  [&shapes](const change_shape_color& y)
                  {
                      // Revert shape color change.
                      shapes[y._id].set_color(y._previous);
                  },
                  [](auto)
                  {
                      // Produce a compile-time error.
                      struct undo_not_implemented;
                      undo_not_implemented{};
                  });
}

如果每个分支match变大,它可以移动到它自己的功能以便于阅读.尝试实例化undo_not_implemented或使用依赖项 static_assert也是一个好主意:如果您忘记实现特定"可撤消操作"的行为,将产生编译时错误.

这就是它!如果要保存undo_stack操作历史记录以保存已保存的文档,则可以auto serialize(const undoable_action&)再次使用模式匹配来序列化各种操作.然后,您可以实现deserialize重新填充undo_stack文件加载的函数.

如果您发现对每个操作执行序列化/反序列化过于繁琐,请考虑使用BOOST_HANA_DEFINE_STRUCT或类似的解决方案来自动生成序列化/反序列化代码.

由于您关注电池和性能,我还想提一下,与多态层次结构相比,使用std::variant或类似的标记联合构造平均更快,更轻量级,因为不需要堆分配,也没有运行时virtual调度.

关于redo功能:您可以拥有redo_stack并实现一个auto invert(const undoable_action&)反转操作行为的函数.例:

void undo()
{
    auto action = undo_stack.pop_and_get();
    match(action, [&](const move_shape& y)
                  {
                      // Revert shape movement.
                      shapes[y._id].move(-y._offset);
                      redo_stack.push(invert(y));  
                  },
                  // ...

auto invert(const undoable_action& x)
{
    return match(x, [&](move_shape y)
                {
                    y._offset *= -1;
                    return y;
                },
                // ...

如果按照这个模式,可以实现redo在以下方面undo!只需undo通过弹出redo_stack而不是undo_stack:弹出来调用,因为你"反转"了它将执行所需操作的动作.

编辑:这是一个最小的wandbox示例,它实现了一个match接受变量并返回变量的函数.

该示例用于boost::hana::overload生成访问者.

访问者包含在lambda中f,该lambda 将返回类型统一到变体的类型:这是必需的std::visit,因为访问者总是返回相同的类型.

如果需要返回与变体不同的类型,则std::common_type_t可以使用,否则用户可以明确地将其指定为第一个模板参数match.

在框架Flip和ODB中实现了解决此问题的两种合理方法.

代码生成/ ODB

使用ODB,您需要为#pragma代码添加声明,并使用它的工具生成方法,用于保存/加载和编辑模型,如下所示:

#pragma db object
class person
{
public:
    void setName (string);
    string getName();
    ...
private:
    friend class odb::access;
    person () {}

    #pragma db id
    string email_;

    string name_;
 };

在类中声明的访问器由ODB自动生成,以便可以捕获对模型的所有更改,并且可以为它们执行撤消事务.

反射最小样板/翻转

与ODB不同,Flip不会为您生成C++代码,而是需要您的程序调用Model::declare以重新声明您的结构,如下所示:

class Song : public flip::Object
{
public:
    static void declare ();
    flip::Float tempo;
    flip::Array  tracks;
};

void Song::declare ()
{
    Model::declare  ()
    .name ("acme.product.Song")
    .member  ("tempo");
    .member , &Song::tracks> ("tracks");
}

int main()
{
    Song::declare();
    ...
}

通过这样的结构化声明,flip::Object构造函数可以初始化所有字段,以便它们可以指向撤消堆栈,并记录它们上的所有编辑.它还有一个包含所有成员的列表,以便flip::Object为您实现序列化.

上述简单方法的问题在于它需要很多容易出错的样板工作.

我会说实际的问题是你的撤销/重做逻辑是一个组件的一部分,它应该只将一堆数据作为一个位置,一个内容等运送.

将撤消/重做逻辑与数据分离的常见OOP方法是命令设计模式.
基本思想是将所有用户交互转换为命令,并在图表本身上执行这些命令.它们包含执行操作和回滚所需的所有信息,只要您维护一个排序的命令列表并按顺序撤消/重做它们(通常是用户期望的).

另一种常见的OOP模式可以帮助您设计自定义序列化实用程序或使用最常见的OOP模式是访问者设计模式.
这里的基本思想是你的图表不应该关心它包含的组件类型.无论何时您想要序列化它,您都会提供一个序列化程序,并且组件在查询时会将它们提升为正确的类型(有关此技术的更多详细信息,请参阅double dispatching).

话虽如此,一个最小的例子值得超过千言万语:

#include 
#include 
#include 
#include 
#include 
#include 
#include 

struct Serializer;

struct Part {
    virtual void accept(Serializer &) = 0;
    virtual void draw() = 0;
};

struct Node: Part {
    void accept(Serializer &serializer) override;
    void draw() override;
    std::string label;
    unsigned int x;
    unsigned int y;
};

struct Link: Part {
    void accept(Serializer &serializer) override;
    void draw() override;
    std::weak_ptr from;
    std::weak_ptr to;
};

struct Serializer {
    void visit(Node &node) {
        std::cout << "serializing node " << node.label << " - x: " << node.x << ", y: " << node.y << std::endl;
    }

    void visit(Link &link) {
        auto pfrom = link.from.lock();
        auto pto = link.to.lock();
       std::cout << "serializing link between " << (pfrom ? pfrom->label : "-none-") << " and " << (pto ? pto->label : "-none-") << std::endl;
    }
};

void Node::accept(Serializer &serializer) {
    serializer.visit(*this);
}

void Node::draw() {
    std::cout << "drawing node " << label << " - x: " << x << ", y: " << y << std::endl;
}

void Link::accept(Serializer &serializer) {
    serializer.visit(*this);
}

void Link::draw() {
    auto pfrom = from.lock();
    auto pto = to.lock();

    std::cout << "drawing link between " << (pfrom ? pfrom->label : "-none-") << " and " << (pto ? pto->label : "-none-") << std::endl;
}

struct TreeDiagram;

struct Command {
    virtual void execute(TreeDiagram &) = 0;
    virtual void undo(TreeDiagram &) = 0;
};

struct TreeDiagram {
    std::vector> parts;
    std::stack> commands;

    void execute(std::unique_ptr command) {
        command->execute(*this);
        commands.push(std::move(command));
    }

    void undo() {
        if(!commands.empty()) {
            commands.top()->undo(*this);
            commands.pop();
        }
    }

    void draw() {
        std::cout << "draw..." << std::endl;
        for(auto &part: parts) {
            part->draw();
        }
    }

    void serialize(Serializer &serializer) {
        std::cout << "serialize..." << std::endl;
        for(auto &part: parts) {
            part->accept(serializer);
        }
    }
};

struct AddNode: Command {
    AddNode(std::string label, unsigned int x, unsigned int y):
        label{label}, x{x}, y{y}, node{std::make_shared()}
    {
        node->label = label;
        node->x = x;
        node->y = y;
    }

    void execute(TreeDiagram &diagram) override {
        diagram.parts.push_back(node);
    }

    void undo(TreeDiagram &diagram) override {
        auto &parts = diagram.parts;
        parts.erase(std::remove(parts.begin(), parts.end(), node), parts.end());
    }

    std::string label;
    unsigned int x;
    unsigned int y;
    std::shared_ptr node;
};

struct AddLink: Command {
    AddLink(std::shared_ptr from, std::shared_ptr to):
        link{std::make_shared()}
    {
        link->from = from;
        link->to = to;
    }

    void execute(TreeDiagram &diagram) override {
        diagram.parts.push_back(link);
    }

    void undo(TreeDiagram &diagram) override {
        auto &parts = diagram.parts;
        parts.erase(std::remove(parts.begin(), parts.end(), link), parts.end());
    }

    std::shared_ptr link;
};

struct MoveNode: Command {
    MoveNode(unsigned int x, unsigned int y, std::shared_ptr node):
        px{node->x}, py{node->y}, x{x}, y{y}, node{node}
    {}

    void execute(TreeDiagram &) override {
        node->x = x;
        node->y = y;
    }

    void undo(TreeDiagram &) override {
        node->x = px;
        node->y = py;
    }

    unsigned int px;
    unsigned int py;
    unsigned int x;
    unsigned int y;
    std::shared_ptr node;
};

int main() {
    TreeDiagram diagram;
    Serializer serializer;

    auto addNode1 = std::make_unique("foo", 0, 0);
    auto addNode2 = std::make_unique("bar", 100, 50);
    auto moveNode2 = std::make_unique(10, 10, addNode2->node);
    auto addLink = std::make_unique(addNode1->node, addNode2->node);

    diagram.serialize(serializer);    
    diagram.execute(std::move(addNode1));
    diagram.execute(std::move(addNode2));
    diagram.execute(std::move(addLink));
    diagram.serialize(serializer);
    diagram.execute(std::move(moveNode2));
    diagram.draw();
    diagram.undo();
    diagram.undo();
    diagram.serialize(serializer);
}

我没有实现重做动作,代码远不是一个生产就绪的软件,但它作为一个起点可以创建更复杂的东西.

如您所见,目标是创建一个包含两个节点和链接的树形图.一个组件包含一堆数据,并知道如何绘制自己.此外,正如预期的那样,组件接受序列化程序,以防您想将其写在文件或其他任何内容上.
所有逻辑都包含在所谓的命令中.在该示例中,有三个命令:添加节点,添加链接和移动节点.图表和组件都不知道发生了什么事情.图表所知道的就是它正在执行一组命令,那些命令可以在当时执行一步.

更复杂的撤销/重做系统可以包含循环的命令缓冲区和一些索引,这些索引指示用下一个替换的索引,一个在前进时有效,一个在返回时有效.
实际上很容易实现.

这种方法将帮助您将逻辑与数据分离,并且在处理用户界面时非常常见.
说实话,这不是突然出现在我脑海里的东西.我在查看开源软件如何解决这个问题时发现了类似的东西,几年前我在我的软件中使用过它.生成的代码非常易于维护.