observer-pattern

Is the observer design pattern already defined in STL (Like the java.util.Observer and java.util.Observable in Java) ? Hogan Here is a reference implementation (from Wikipedia ). #include <iostream> #include <string> #include <map> #include <boost/foreach.hpp> class SupervisedString; class IObserver{ public: virtual void handleEvent(const SupervisedString&) = 0; }; class SupervisedString{ // Observable class std::string _str; std::map<IObserver* const, IObserver* const> _observers; typedef std::map<IObserver* const, IObserver* const>::value_type item; void _Notify(){ BOOST_FOREACH(item iter,

As I understand it, the observer pattern allows for multiple observers to monitor a single subject. Is there a pattern for the opposite scenario? Is there a pattern for a single observer that monitors several subjects and responds when any one of them raises, say, a Notify event? The Observer pattern can still be used: just have the same object register as an observer to many monitored objects. You'll probably want the "Notify" event to receive some kind of observed-object identifier (the "this" pointer, a unique id number etc) so that the observer object can choose an action appropriate to

I'm using restful_authentication in my app. I'm creating a set of default users using a rake task, but every time I run the task an activation email is sent out because of the observer associated with my user model. I'm setting the activation fields when I create the users, so no activation is necessary. Anyone know of an easy way to bypass observers while running a rake task so that no emails get sent out when I save the user? Thanks. You could add an accessor to your user model, something like "skip_activation" that wouldn't need to be saved, but would persist through the session, and then

I divided my problem into a short and a long version for the people with little time at hand. Short version: I need some architecture for a system with provider and consumer plugins. Providers should implement intereface IProvider and consumers should implement IConsumer. The executing application should only be aware of IProvider and IConsumer. A consumer implementation can ask the executing assembly (by means of a ServiceProcessor) which providers implement InterfaceX and gets a List back. These IProvider objects should be casted to InterfaceX (in the consumer) to be able to hook the

I would like to be able to run some functionality with a module that I am building whenever a customer registers an account, but I can't seem to find any event that is fired upon a new customer registration . Does anybody know of an event that is dispatched for that? Whenever I'm looking for an event, I'll temporarily edit the Mage.php file to output all the events for a particular request. File: app/Mage.php public static function dispatchEvent($name, array $data = array()) { Mage::log('Event: ' . $name); //not using Mage::log, as //file_put_contents('/tmp/test.log','Dispatching '. $name. "\n

I'd like to run some code whenever an email is sent on my app. As ActionMailer doesn't support after_filter, I would like to use an observer. The Rails docs mention this in passing, however does not elaborate. Thanks! I'm surprised how little there is in Rails' documentation about this. Basically, ActionMailer in Rails 3 introduces the use of Interceptors (called before the message is sent) and Observers (after the message is sent). To set up an Observer, add the following to an initializer: class MailObserver def self.delivered_email(message) # Do whatever you want with the message in here

What are the pros and cons of keeping listeners as WeakReferences. The big 'Pro' of course is that: Adding a listener as a WeakReference means the listener doesnt need to bother 'removing' itself. Update For those worried about the listener having the only reference to the object, why cant there be 2 methods, addListener() and addWeakRefListener()? those who dont care about removal can use the latter. BegemoT First of all, using WeakReference in listeners lists will give your object different semantic , then using hard references. In hard-reference case addListener(...) means "notify supplied

I want to implement the Observable pattern in Python for a couple of workers, and came across this helpful snippet: class Event(object): pass class Observable(object): def __init__(self): self.callbacks = [] def subscribe(self, callback): self.callbacks.append(callback) def fire(self, **attrs): e = Event() e.source = self for k, v in attrs.iteritems(): setattr(e, k, v) for fn in self.callbacks: fn(e) Source: Here As i understand it, in order to subscribe , I would need to pass a callback to the function that is going to be called on fire . If the calling function was a class method, presumably

Java 9 came out, and Observer has been deprecated. Why is that? Does it mean that we shouldn't implement observer pattern anymore? It would be good to know what is a better alternative? Naman Why is that? Does it mean that we shouldn't implement observer pattern anymore? Answering the latter part first - YES , it does mean you shouldn't implement Observer and Obervable s anymore. Why were they deprecated - They didn't provide a rich enough event model for applications. For example, they could support only the notion that something has changed, but didn't convey any information about what has