我想创建一个用户可以编辑图表的应用程序(例如),它将提供以下标准机制:保存,加载,撤消和重做.
一个简单的方法是为图表及其中的各种形状提供类,通过保存和加载方法实现序列化,并且所有编辑它们的方法都返回UndoableAction可以添加到UndoManager调用其perform方法和将它们添加到撤消堆栈.
上述简单方法的问题在于它需要很多容易出错的样板工作.
我知道工作的序列化(保存/加载)部分可以通过使用像Google的Protocol Buffers或Apache Thrift这样的东西来解决,它会为你生成样板序列化代码,但它不能解决undo + redo问题.我知道对于Objective C和Swift,Apple提供了解决序列化和撤销的核心数据,但我不熟悉C++的类似内容.
是否有一个很好的方法非容易错误解决save + load + undo + redo只有很少的样板？
Vit*_*meo 11
上述简单方法的问题在于它需要很多容易出错的样板工作.
我不相信这是事实.您的方法听起来很合理,使用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
以下是您的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.使用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 <Track> tracks;
};
void Song::declare ()
{
Model::declare <Song> ()
.name ("acme.product.Song")
.member <flip::Float, &Song::tempo> ("tempo");
.member <flip::Array <Track>, &Song::tracks> ("tracks");
}
int main()
{
Song::declare();
...
}
通过这样的结构化声明,flip::Object构造函数可以初始化所有字段,以便它们可以指向撤消堆栈,并记录它们上的所有编辑.它还有一个包含所有成员的列表,以便flip::Object为您实现序列化.
上述简单方法的问题在于它需要很多容易出错的样板工作.
我会说实际的问题是你的撤销/重做逻辑是一个组件的一部分,它应该只将一堆数据作为一个位置,一个内容等运送.
将撤消/重做逻辑与数据分离的常见OOP方法是命令设计模式.
基本思想是将所有用户交互转换为命令,并在图表本身上执行这些命令.它们包含执行操作和回滚所需的所有信息,只要您维护一个排序的命令列表并按顺序撤消/重做它们(通常是用户期望的).
另一种常见的OOP模式可以帮助您设计自定义序列化实用程序或使用最常见的OOP模式是访问者设计模式.
这里的基本思想是你的图表不应该关心它包含的组件类型.无论何时您想要序列化它,您都会提供一个序列化程序,并且组件在查询时会将它们提升为正确的类型(有关此技术的更多详细信息,请参阅double dispatching).
话虽如此,一个最小的例子值得超过千言万语:
#include <memory>
#include <stack>
#include <vector>
#include <utility>
#include <iostream>
#include <algorithm>
#include <string>
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<Node> from;
std::weak_ptr<Node> 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<std::shared_ptr<Part>> parts;
std::stack<std::unique_ptr<Command>> commands;
void execute(std::unique_ptr<Command> 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>()}
{
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> node;
};
struct AddLink: Command {
AddLink(std::shared_ptr<Node> from, std::shared_ptr<Node> to):
link{std::make_shared<Link>()}
{
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> link;
};
struct MoveNode: Command {
MoveNode(unsigned int x, unsigned int y, std::shared_ptr<Node> 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> node;
};
int main() {
TreeDiagram diagram;
Serializer serializer;
auto addNode1 = std::make_unique<AddNode>("foo", 0, 0);
auto addNode2 = std::make_unique<AddNode>("bar", 100, 50);
auto moveNode2 = std::make_unique<MoveNode>(10, 10, addNode2->node);
auto addLink = std::make_unique<AddLink>(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);
}
我没有实现重做动作,代码远不是一个生产就绪的软件,但它作为一个起点可以创建更复杂的东西.
如您所见,目标是创建一个包含两个节点和链接的树形图.一个组件包含一堆数据,并知道如何绘制自己.此外,正如预期的那样,组件接受序列化程序,以防您想将其写在文件或其他任何内容上.
所有逻辑都包含在所谓的命令中.在该示例中,有三个命令:添加节点,添加链接和移动节点.图表和组件都不知道发生了什么事情.图表所知道的就是它正在执行一组命令,那些命令可以在当时执行一步.
更复杂的撤销/重做系统可以包含循环的命令缓冲区和一些索引,这些索引指示用下一个替换的索引,一个在前进时有效,一个在返回时有效.
实际上很容易实现.
这种方法将帮助您将逻辑与数据分离,并且在处理用户界面时非常常见.
说实话,这不是突然出现在我脑海里的东西.我在查看开源软件如何解决这个问题时发现了类似的东西,几年前我在我的软件中使用过它.生成的代码非常易于维护.
假设您为图表的每次编辑调用临时文件上的 save() （即使用户没有显式调用保存操作）并且您仅撤消最新操作，您可以执行以下操作：
LastDiagram load(const std::string &path)
{
/* Check for valid path (e.g. boost::filesystem here) */
if(!found)
{
throw std::runtime_exception{"No diagram found"};
}
//read LastDiagram
return LastDiagram;
}
LastDiagram undoLastAction()
{
return loadLastDiagram("/tmp/tmp_diagram_file");
}
在您的主应用程序中，您可以处理抛出的异常。如果您想允许更多撤消，那么您应该考虑使用 sqlite 或具有更多条目的 tmp 文件之类的解决方案。
如果由于大图表而导致时间和空间上的性能问题，请考虑实施一些策略，例如在 std::vector 中为图表的每个元素保留增量差异（如果对象很大，则将其限制为 3/5）并调用渲染器与目前的状态。我不是 OpenGL 专家，但我认为这就是它的实现方式。实际上，您可以从游戏开发最佳实践或通常与图形相关的最佳实践中“窃取”此策略。
其中一种策略可能是这样的：