c++ - 观察者设计模式问题

Question

我正在使用C++进行大型项目，该项目将具有图形用户界面。
用户界面将使用一些依赖于观察者模式的设计模式(MVVM / MVC)。

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

由于这个问题，我发现自己被拉向多个方向:

如果我开发不支持通知的后端类，我会发现自己违反了开放-封闭原则。

如果我确实提供对所有Model类及其所有数据成员的通知的支持，这将导致巨大的性能成本，这是不合理的，因为实际上仅需要这种支持的一部分(即使这一部分是未知的)。

如果我仅通过将所有非const方法设为虚拟并通过基指针访问这些方法来提供对扩展的支持，则也是如此。这也将增加可读性。

我认为这3个(1.)中的邪恶程度可能较小。

但是，我觉得理想的解决方案实际上应该以某种语言(肯定不是C++)存在，但是我不知道它是否在任何地方都受支持。

我想到的独角兽解决方案是这样的:
给定一类数据，寻求使数据可观察的客户是否应该这样做？

@MakeObservable(数据)

作为编译时构造。反过来，这将使得可以在Data对象上调用addObserver并使用通知程序修改对数据成员的所有分配。这也将使您只为获得的成果付费。

所以我的问题有两个:

我是否应该假设我说过的3个选项中，(1。)是次要但必要的邪恶？

我的独角兽解决方案是否存在？正在工作？还是由于某种原因无法实现？

Answer 1

如果我理解正确，那么您担心为每个对象的每个可能的property提供信号/通知的成本。

幸运的是，您很幸运，因为使用任何对象或系统的每个对象的每个属性存储通用的线程安全通知程序通常会非常昂贵。

我建议您不要聪明地尝试在编译时解决此问题，因为我建议将其排除在大型项目的某些非常潜在有用的选项(例如:插件和脚本编制)之外，建议您考虑如何制作在运行时更便宜。您希望将信号存储在比对象的各个属性更粗糙的级别上。

如果您仅存储一个带有传递适当数据的对象，该对象传递有关在属性更改事件期间修改了哪个属性以过滤要通知的客户端的信息，那么现在我们便宜很多。我们正在为连接的插槽交换一些其他的分支和较大的聚合，但是您得到的对象明显较小，但可能具有更快的读取访问权，我建议这在实践中是非常有值(value)的交换。

您仍然可以设计公共(public)接口(interface)，甚至可以设计事件通知机制，以使客户端使用系统的方式就像连接到属性而不是整个对象一样，甚至可以调用属性中的方法(如果它是对象) / proxy)来连接插槽(如果需要)或可以从属性提供指向对象的后向指针。

如果您不确定，我会在将事件槽附加到属性以及将其作为对象接口(interface)而不是属性接口(interface)的一部分进行修改方面犯错，因为您将有更多的喘息空间来优化以换取客户端美学略有不同(我真的不认为它不那么方便，只是“不同”，或者至少有可能值得消除每个属性的反向指针)。

那就是方便和包装类型的东西。但是，您无需违反开放式原则即可在C++中实现MVP设计。不要因数据表示而陷入困境。在公共(public)接口(interface)级别，您具有很大的灵活性。

内存压缩-支付我们使用的费用

在发现效率在这里起重要作用时，我建议一些基本的思考方法来帮助实现这一目标。

首先，仅因为对象具有某种类似于something()的访问器，并不意味着相关数据必须存储在该对象中。在调用该方法之前，它甚至不必存储在任何地方。如果您关心内存，则可以将其存储在外部的某个级别。

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

如果您希望在设计上几乎不用为不使用的东西付出任何内存成本，那么您希望将数据与对象进行更粗略的关联。如果将其直接存储在对象中，则每个对象都将为something()返回的内容付费，而不管是否需要它。如果使用指针将其间接存储在对象中，则需要为something()的指针付费，但除非使用它，否则不支付其全部费用。如果将其与对象的所有者相关联，则检索该对象将具有查找成本，但是成本不如将其与对象的所有者相关联那样昂贵。

因此，如果您在足够粗糙的级别上进行关联，总有总有一些方法可以使您不需要的东西非常接近免费。在粒度级别上，您可以减轻查找和间接开销，而在粗糙级别上，您可以减少不使用的东西的成本。

大规模 Activity

考虑到要处理成千上万到数十亿个元素的巨大的可伸缩性问题，并且仍然希望它们中的一些可能生成事件，如果您可以使用异步设计，那么我在这里真的推荐它。您可以有一个无锁的每线程事件队列，设置了单个位标志的对象将在该队列中生成事件。如果未设置位标志，则不会设置。

这种延迟的异步设计在这样的规模下很有用，因为它为您提供了周期性的间隔(或者可能只是其他线程，尽管您需要写锁，但也需要读锁，尽管写需要便宜)。在这种情况下)，可以轮询并投入全部资源来批量处理队列，而对时间要求更高的处理可以继续进行，而无需与事件/通知程序系统同步。

基本范例

// 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创建一个关联结构，该结构将object / event_id映射到客户端。 disconnect还将其从该中央线程源中删除。甚至将插槽与信号连接/从信号断开连接的操作，都可以推送到事件队列，以在中央，全局位置进行处理并进行适当的关联(再次防止没有观察者的对象支付任何内存成本)。

使用这种类型的设计时，每个线程应在其入口点处具有该线程的退出处理程序，该处理程序将推送到线程事件队列的事件从线程本地队列传输到某个全局队列。这需要一个锁定，但是可以不太频繁地完成，以避免繁重的争用，并避免在性能至关重要的区域中事件处理降低每个线程的速度。同样，应该为这种类型的设计提供某种thread_yield类型的功能，该设计也将从线程本地队列转移到全局队列，以维护长期存在的线程/任务。

全局队列在不同的线程中处理，触发适当的信号到连接的插槽。在那里，它可以专注于在不为空时对队列进行批量处理，在为空时进行睡眠/屈服处理。所有这些的全部目的是为了提高性能:与每次修改对象属性时发送同步事件的可能性相比，将其推送到队列非常便宜，而在处理大规模输入时，这可能是非常昂贵的开销。因此，只需将其推送到队列中，该线程就可以避免在事件处理上花费时间，将其推迟到另一个线程。