TheGreatCthulhu, thanks for pointing to the Mediator pattern. Some of you may know I'm not quite good at design patterns, and this is one of those I didn't know yet. And the Mediator pattern seems to definitely be a candidate to consider for the one of my apps I'm currently dedicating most of my programming time to. And actually I already have considered a similar design, I just wouldn't have called the central coordinating instance "mediator", rather, by nature of the app, something like "hub" or "data pump". And of course I had no idea there's a related standard design pattern... (Also, it's currently the app itself that plays that role, and that was something I already was sure of that it needs to be changed.)
To summarize what the app is about: Some of you may know I always wanted an alternative to the terrible Windows Performance Monitor, and recently I had some spare time, so I stated my own one. There currently are these categories of "colleagues":
Sample sources: Provide an (ideally but not necessarily) continuous stream of timestamped numerical sample values.
Event mark sources: Provide timestamped notification of instantaneous events. They don't carry sample values but may convey additional information like, for instance, the originator of the event.
Consumers: Simply do what the name suggests. Currently the only instance of this is the chart that displays the samples and events.
Triggers: Act as both consumers of sample streams and/or events and issue events based on some condition, for instance when a certain number of consecutive samples from a certain source exceed a certain value.
I'm also envisioning another category ("operator", perhaps) that acts as a consumer and produces a sample stream as output, but that idea is rather abstract and by now I don't know any concrete scenario where that actally might be useful. And out of the bulleted list above, only the first three items have actually been implemented by now.
Of course this scenario is way more complex than the simple examples of the Mediator pattern I found since reading your post, but actually I rather consider this an advantage: The minimalistic examples help to focus on the core aspects of the pattern and loosing the visible connection between my implementation and the pattern examples may be a warning to perhaps rethink parts of my design.
There are, however, some aspects in which I definitely must deviate from the sample designs due to the naure of my app: My design must definitely support event-driven action and, at least to some extent, multithreading, so it can't be so strictly sequential. Also, it's probably a good idea to allow the colleagues to choose between communicating with the mediator in an event-driven manner or by polling. At least in the latter case, the mediator will probably need to provide buffering queues for the colleagues, so these don't need to implement the same thing over and over.
Proper abstraction at a stage as early as possible is also desirable here since I plan to expose a plug-in interface so colleagues can be added externally.
Any thoughts? Perhaps Mediator even is the wrong pattern for my scenario; as stated above: There's quite a bunch of them I don't even know yet...
Moderator Comment: Note: this thread was split by request from this thread.
Last edited by Arjay; November 16th, 2012 at 03:25 PM.