Question

我正在使用C ++开发一个具有图形用户界面的大型项目。用户界面将使用一些依赖于观察者模式的设计模式（MVVM / MVC）。

我的问题是我目前无法预测模型的哪些部分应该是可观察的。并且有很多很多部分。

由于这个问题，我发现自己被拉向了几个方向：

如果我开发不支持通知的后端课程，我会发现自己违反了开放式原则。
如果我确实为所有Model类及其所有数据成员提供通知支持，那么它将具有大量的性能成本，这是不合理的，因为实际上只需要一小部分支持（即使这部分未知）。
如果我只通过使所有非const方法虚拟并通过基指针访问这些方法来提供对扩展的支持，情况也是如此。这也会带来可读性。

我觉得在这3个中，（1。）可能是较小的邪恶。

然而，我觉得理想的解决方案应该存在于某种语言中（绝对不是C ++），但我不知道它是否在任何地方都受到支持。

我想到的独角兽解决方案是这样的：给定一个类数据，不应该寻求使数据可观察的客户做类似的事情

@MakeObservable（数据）

作为编译时构造。这反过来又可以在Data对象上调用addObserver并使用通知程序修改对数据成员的所有赋值。它也会让你只为你得到的东西付出代价。

所以我的问题是双重的：

我是否正确地假设我所说的3个选项中，（1。）是较小但必要的邪恶？
我的独角兽解决方案是否存在于任何地方？正在努力？或者因某种原因无法实施？

Answer 1

如果我理解正确，您就会关注为每个对象的每个可观察property提供信号/通知的费用。

幸运的是，您很幸运，因为在每个对象的每个属性中存储一般线程安全通知程序通常在任何语言或系统中都非常昂贵。

而不是让所有人都聪明并且在编译时试图解决这个问题，我建议将一些非常有用的选项关闭到一个大型项目（例如：插件和脚本），我建议思考如何在运行时降低成本。您希望信号存储在比对象的各个属性更粗糙的级别。

如果您只存储一个对象，该对象传递了有关在属性更改事件期间修改了哪个属性的相应数据，以过滤要通知的客户端，那么现在我们可以获得更低的价格。我们正在为连接的插槽交换一些额外的分支和更大的聚合，但是您可以获得一个更小的对象，以换取更快的读取访问权限，并且我建议这在实践中是非常有价值的交换。

您仍然可以设计公共接口甚至事件通知机制，以便客户端以一种感觉就像他们连接到属性而不是整个对象的方式一起工作，甚至可能调用属性中的方法（如果它是一个对象/代理）如果你需要或者能够从一个属性中获得一个指向该对象的后向指针来连接插槽。

如果您不确定，我会错误地将事件槽附加到属性以及将它们作为对象接口的一部分而不是属性界面进行修改，因为您将拥有更多呼吸空间进行优化以换取略微不同的客户美学（我真的不认为不那么方便，只是“不同”，或者至少可能值得消除背部的成本每个属性的指针）。

在便利和包装类型的东西中。但是，您不需要违反开放封闭原则来实现C ++中的MVP设计。不要通过数据表示塞进一个角落。您在公共接口级别具有很大的灵活性。

记忆压缩 - 支付我们使用的东西

在发现效率在这里发挥重要作用时，我建议一些基本的思维方式来帮助解决这个问题。

首先，仅仅因为一个对象有一些像something()这样的访问者并不意味着必须将相关数据存储在该对象中。在调用该方法之前，它甚至不必存储在任何地方。如果您关心内存，可以将其存储在外面的某个级别。

大多数软件都分解为拥有资源的聚合的层次结构。例如，在3D软件中，顶点由网格所拥有，网格由应用程序根拥有的场景图所拥有。

如果您希望设计中几乎不会为未使用的内容支付任何内存成本，那么您希望将数据与较粗糙的对象关联。如果将它直接存储在对象中，那么无论是否需要，每个对象都会为something()返回付出代价。如果使用指针将其间接存储在对象中，则需要为指向something()的指针付费，但除非使用指针，否则不会支付全部费用。如果将它与对象的所有者相关联，那么检索它有一个查找成本，但不像将它与对象所有者的所有者相关联那样昂贵。

因此，如果您在足够粗糙的水平上关联，那么总是可以获得非常接近免费的东西。在粒度级别，您可以减少查找和间接开销，在粗略级别可以降低您不使用的内容的成本。

大规模活动

鉴于数百万到数十亿个元素正在处理大量可扩展性问题，并且仍然希望其中一些元素能够生成事件，如果您可以使用异步设计，我在这里真的推荐它。您可以拥有一个无锁的每线程事件队列，具有单个位标志的对象将生成事件。如果未设置位标志，则不会。

这种延迟的异步设计对于这样的比例是有用的，因为它给你定期的间隔（或者可能只是其他线程，虽然你需要写锁 - 以及读锁，尽管写作是需要的廉价 - 在这种情况下），其中轮询和投入全部资源来批量处理队列，而更时间关键的处理可以继续而不与事件/通知者系统同步。

基本示例

// Interned strings are very useful here for fast lookups
// and reduced redundancy in memory.
// They're basically just indices or pointers to an 
// associative string container (ex: hash or trie).

// Some contextual class for the thread storing things like a handle
// to its event queue, thread-local lock-free memory allocator, 
// possible error codes triggered by functions called in the thread,
// etc. This is optional and can be replaced by thread-local storage 
// or even just globals with an appropriate lock. However, while
// inconvenient, passing this down a thread's callstack is usually 
// the most efficient and reliable, lock-free way.
// There may be times when passing around this contextual parameter
// is too impractical. There TLS helps in those exceptional cases.
class Context;

// Variant is some generic store/get/set anything type. 
// A basic implementation is a void pointer combined with 
// a type code to at least allow runtime checking prior to 
// casting along with deep copying capabilities (functionality
// mapped to the type code). A more sophisticated one is
// abstract and overriden by subtypes like VariantInt
// or VariantT<int>
typedef void EventFunc(Context& ctx, int argc, Variant** argv);

// Your universal object interface. This is purely abstract:
// I recommend a two-tier design here: 
// -- ObjectInterface->Object->YourSubType
// It'll give you room to use a different rep for 
// certain subtypes without affecting ABI.
class ObjectInterface
{
public:
     virtual ~Object() {}

     // Leave it up to the subtype to choose the most
     // efficient rep.
     virtual bool has_events(Context& ctx) const = 0;

     // Connect a slot to the object's signal (or its property 
     // if the event_id matches the property ID, e.g.).
     // Returns a connection handle for th eslot. Note: RAII 
     // is useful here as failing to disconnect can have 
     // grave consequences if the slot is invalidated prior to 
     // the signal.
     virtual int connect(Context& ctx, InternedString event_id, EventFunc func, const Variant& slot_data) = 0;

     // Disconnect the slot from the signal.
     virtual int disconnect(Context& ctx, int slot) = 0;

     // Fetches a property with the specified ID O(n) integral cmps.
     // Recommended: make properties stateless proxies pointing
     // back to the object (more room for backend optimization).
     // Properties can have set<T>/get<T> methods (can build this
     // on top of your Variant if desired, but a bit more overhead
     // if so).
     // If even interned string compares are not fast enough for
     // desired needs, then an alternative, less convenient interface
     // to memoize property indices from an ID might be appropriate in
     // addition to these.
     virtual Property operator[](InternedString prop_id) = 0;

     // Returns the nth property through an index.
     virtual Property operator[](int n) = 0;

     // Returns the number of properties for introspection/reflection.
     virtual int num_properties() const = 0;

     // Set the value of the specified property. This can generate
     // an event with the matching property name to indicate that it
     // changed.
     virtual void set_value(Context& ctx, InternedString prop_id, const Variant& new_value) = 0;

     // Returns the value of the specified property.
     virtual const Variant& value(Context& ctx, InternedString prop_id) = 0;

     // Poor man's RTTI. This can be ignored in favor of dynamic_cast
     // for a COM-like design to retrieve additional interfaces the
     // object supports if RTTI can be allowed for all builds/modes.
     // I use this anyway for higher ABI compatibility with third
     // parties.
     virtual Interface* fetch_interface(Context& ctx, InternedString interface_id) = 0;
};

我将避免深入研究数据表示的细节 - 整点是它的灵活性。重要的是自己购买房间以根据需要进行更改。保持对象抽象，将属性保持为无状态代理（除了对象的后向指针）等，为分析和优化提供了大量的喘息空间。

对于异步事件处理，每个线程都应该有一个关联的队列，可以通过这个Context句柄向下传递给调用堆栈。当事件发生时（例如属性更改），如果has_events() == true，对象可以通过它将事件推送到此队列。同样，connect并不一定要向对象添加任何状态。它可以再次通过Context创建关联结构，将对象/ event_id映射到客户端。 disconnect也会将其从该中心线程源中删除。即使是将信号连接/断开信号的行为，也可以推送到事件队列，以便处理和建立适当的关联（再次防止没有观察者的对象支付任何内存成本）。

使用这种类型的设计时，每个线程的入口点应该有一个线程的退出处理程序，它将推送到线程事件队列的事件从线程本地队列传输到某个全局队列。这需要锁定，但可以不频繁地进行以避免严重争用，并且在性能关键区域期间允许每个线程不会因事件处理而减慢速度。同样应该为某种类型的thread_yield类型的函数提供这样的设计，该设计也从线程本地队列转移到长期线程/任务的全局队列。

全局队列在不同的线程中处理，触发到连接的插槽的适当信号。在那里它可以专注于在队列不空时对其进行批量处理，当它处于休眠状态时休眠/产生。所有这一切的全部意义在于提高性能：与每次修改对象属性时发送同步事件的可能性相比，推送到队列是非常便宜的，并且当使用大规模输入时，这可能是非常昂贵的开销。因此，简单地推送到队列允许该线程避免花时间在事件处理上，将其推迟到另一个线程。

Answer 2

Templatious库可以帮助您完全解耦GUI和域逻辑，并灵活/可扩展/易于维护消息系统和通知程序。

但是，有一个缺点 - 你需要C ++ 11支持。

查看这篇文章taming qt 以及github中的示例：DecoupledGuiExamples

因此，您可能不需要在每个类上使用通知程序，您可以从内部函数和特定类中发送消息，您可以在其中使任何类发送您想要GUI的任何消息。

观察者设计模式问题

2 个答案:

记忆压缩 - 支付我们使用的东西

大规模活动

基本示例