Jump to content
  • Advertisement
Sign in to follow this  

Observer design pattern - Chaining subjects or subjects as observers?

This topic is 4091 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Ever looking for better ways to build things I have been looking into the observer (publisher/subscriber) design pattern. However, I have a particular need that may require an observer (publisher) to also be a subject (subscriber). Basically I want to know if it is considered good practice to allow a Subject -> (Observer/Subject) -> Subject architecture to pass notification messages down the line or if I should attempt redesigning my architecture so that a subject cannot be an observer. A semi-specific example is described below. 1. An SystemMonitor listens for events from a system (e.g., process start, timer, etc) 2. A DataReader subscribes to SystemMonitor and reads data only on specific events (e.g., timer reading from a device on a serial port). 3. A DataWriter subscribes to DataReader and writes data only when notified that DataReader has read data. There is 1-many relationship between SystemMonitor and DataReader (may have many sources to read from). And there is 1-many relationship between DataReader and DataWriter (may want to write data from one source to many different formats). Does this sound viable? Are there other patterns that I might want to look into that fit the bill better? Don't think it matters all that much but I am developing this in C++. So, in psuedo code, it might look something like this.
DataWriter dbWriter = new DbWriter(connectionString);
DataWriter txtWriter = new TextWriter("file.dat");

DataReader serialPortReader = new SerialPortReader("/dev/ttyS0");

SystemMonitor sysMonitor = new SystemMonitor();
sysMonitor.monitor(); // Enter permanent loop and dispatch notifications to observers.

Thoughts? Suggestions?

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!