如何将数据传递给“通用”观察者?作为参数还是作为单个结构?
我正忙于向旧版 C++ 应用程序添加通用观察者机制(使用 Visual Studio 2010,但不使用 .Net,因此不可能使用 .Net 委托)。
在设计中,我希望尽可能地将特定于应用程序的部分与通用观察者机制分开。
实现观察者的最合乎逻辑的方式似乎是这样的:
class IDoThisObserver
{
public:
void handlDoThis(int arg1, int arg2) = 0;
};
对于每种类型的观察者(IDoThisObserver、IDoThatObserver,...),方法(handleDoThis、handleDoThat)的参数都是不同的。
存储观察者的通用方式仍然存在,如下所示:
template<typename T>
class ObserverContainer
{
public:
void addObserver (T &t) {m_observers.push_back(&t);}
private:
std::list<T*> m_observers;
};
调用观察者不能通用,因为每个观察者类型的参数都不同。
另一种方法是将所有参数“打包”到一个参数中,如下所示:
struct DoThisInfo
{
DoThisInfo (int arg1, int arg2) : m_arg1(arg1), m_arg2(arg2) {}
int m_arg1;
int m_arg2;
};
然后定义一个更通用的观察者,如下所示:
template<typename T>
class IObserver
{
public:
void notify(const T &t) = 0;
};
然后这些观察者的集合将变成这样:
template<typename T>
class ObserverContainer
{
public:
void addObserver (IObserver<T> &obs) {m_observers.push_back(&obs);}
private:
std::list<IObserver<T>*> m_observers;
};
现在,可以集中添加更多逻辑这个ObserverContainer,包括调用所有的观察者。呼叫的“发起者”只需创建并填写通知结构。
想要从多种观察者继承的类需要这样做:
class MyObserver : public IObserver<NotifyThis>, public IObserver<NotifyThat>
{
...
};
以下哪种方法(具有多个显式参数或一个结构参数的观察者)似乎是最好的?这两种方法有什么优点或缺点吗?
编辑:我进一步研究了替代方法,槽/信号方法似乎是另一个不错的候选者。我应该了解 Slot/Signal 中的任何重要缺点吗?
I am busy adding a generic observer mechanism to a legacy C++ application (using Visual Studio 2010, but not using .Net, so .Net delegates are out of the question).
In the design I want to separate the application-specific part as much as possible from the generic observer mechanism.
The most logical way of implementing observers seems this way:
class IDoThisObserver
{
public:
void handlDoThis(int arg1, int arg2) = 0;
};
For every type of observer (IDoThisObserver, IDoThatObserver, ...) the arguments of the methods (handleDoThis, handleDoThat) are different.
What remains in a generic way of storing the observers, like this:
template<typename T>
class ObserverContainer
{
public:
void addObserver (T &t) {m_observers.push_back(&t);}
private:
std::list<T*> m_observers;
};
Calling an observer can't be generalized since the arguments are different for every observer type.
An alternative way would be to 'pack' all arguments into one argument, like this:
struct DoThisInfo
{
DoThisInfo (int arg1, int arg2) : m_arg1(arg1), m_arg2(arg2) {}
int m_arg1;
int m_arg2;
};
And then define a more generic observer, like this:
template<typename T>
class IObserver
{
public:
void notify(const T &t) = 0;
};
And a collection of these observers would then become this:
template<typename T>
class ObserverContainer
{
public:
void addObserver (IObserver<T> &obs) {m_observers.push_back(&obs);}
private:
std::list<IObserver<T>*> m_observers;
};
Now, much more logic can be centrally added to this ObserverContainer, including calling all observers. The 'initiator' of the call only needs to create and fill in the notification structure.
Classes that want to inherit from multiple kinds of observers, need to do it like this:
class MyObserver : public IObserver<NotifyThis>, public IObserver<NotifyThat>
{
...
};
Which of these approaches (observers with multiple explicit arguments or with one struct argument) seems the best? Are there any advantages or disadvantages to either of these approaches?
EDIT: I looked a bit further to alternative approaches, and the Slot/Signal approach seems another good candidate. Are there any important disadvantages in Slot/Signal that I should know of?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
我认为您的任何一种方法都不符合您的要求。然而,使用包含传递给所有观察者的数据集的 DataCarrier 进行一点修改,其中每个观察者都知道要读取什么内容,就可以达到目的。下面的示例代码可能会清除它(注意我还没有编译)
这样,如果您添加新结构,您只需修改枚举。
你也可以使用 boost::shared_ptr 来处理混乱的指针。
I don't think either of your approaches would fit your requirement as is. However a little modification using a DataCarrier containing the dataset passed across all the observers wherein each observer would know what to read would do the trick. The sample code below might clear it (note i have not compiled)
This way u need to modify only the enum if u add a new structure.
Also u can use boost::shared_ptr to handle the mess of pointers.
我无法正确理解语法,因此我将列出声明来说明结构。可以使通用观察者期望一个参数,该参数要么是所需参数的特定形式的子类,要么是包含观察者所需的所有原始参数的水平映射的结构。那么 ObserverContainer 就可以充当 AbstractFactory ,并且 ObserverContainer 的每个子类都可以是 DoThatObserverFactory 和 DoThisObserverFactory。工厂将构建一个观察者并向观察者分配一个配置,以告诉它需要哪个参数。
I wouldn't get the syntax right so I'm just going to list the declarations to illustrate the structures. A generic Observer could be made to expect a parameter that is either subclassed to specific forms of your required parameters or is struct including a horizontal mapping of all primitive parameters that will be required by your Observers. Then the ObserverContainer could function as an AbstractFactory and each subclass of the ObserverContainer could be DoThatObserverFactory and DoThisObserverFactory. The factory would build an observer and assign a configuration to the observer to tell it which parameter to expect.
为什么不直接做:
?
那么你有:
Why not just do:
?
Then you have:
使用 struct 参数的设计肯定更好,因为它允许在 ObserverContainer 中编写通用代码。用封装参数的对象替换较长的参数列表通常是一种很好的设计实践,这是回报的一个很好的例子。通过为您的
notify
方法创建更通用的抽象(使用您将notify
定义为需要大量“数据”的方法的结构,而使用 arg 列表,您可以定义一个需要两个数字的方法),您可以自己编写使用该方法的通用代码,而不必关心传入的数据块的确切组成。The design with the
struct
argument is definitely better as it allows for generic code to be written in theObserverContainer
. It's generally a good design practice to replace longish argument lists with objects that encapsulate the arguments and this is a good example of the payoff. By creating a more general abstraction for yournotify
method (with the struct you're definingnotify
as a method that takes a chunk of "data" whereas with the arg list you're defining a method that takes two numbers) you allow yourself to write generic code that uses the method and doesn't have to concern itself with the exact composition of the passed in chunk of data.您研究过 Boost.Signals 吗?比重新实现轮子更好。
至于参数:从概念上讲,调用观察者/槽应该与调用普通函数相同。大多数 SignalSlots 实现都允许多个参数,因此请使用它。并且请针对不同的观察者类型使用不同的信号,这样就不需要在 Variants 中传递数据。
我见过的观察者模式/信号槽的两个缺点:
1)仅看源码很难甚至不可能理解程序流程。
2)具有大量观察者/信号槽的高度动态程序可能会遇到“删除这个”
一切都放在一边,我更喜欢观察者/信号槽而不是子类化,因此高度耦合。
Have you looked into Boost.Signals? Better than to reimplement the wheel.
As for Parameters: Calling an observer/slot should conceptionally be the same as if you would call an ordinary function. Most SignalSlots-Implementations allow multiple Parameters, so use it. And please use different signals for different observer types, then there is no need to pass around data in Variants.
Two Disadvantages of the Observer-Pattern/SignalSlots i have seen:
1) Program flow is difficult or even impossible to understand by looking only at the source.
2) Heavily dynamic programs with lots of Observers/SignalSlots may encounter a "delete this"
Everything aside, i like Observers/SignalSlots more than subclassing and thus high coupling.