How can I take advantage of IObservable/IObserver to get rid of my "god object"?

Question

In a system I'm currently working on, I have many components which are defined as interfaces and base classes. Each part of the system has some specific points where they interact with other parts of the system.

For example, the data readying component readies some data which eventually needs to go to the data processing portion, the communications component needs to query different components for their status for relaying to the outside, etc.

Currently, I glue these parts of the system together using a "god object", or an object with intimate knowledge of different parts of the system. It registers with events over here and shuttles the results to methods over there, creates a callback method here and returns the result of that method over there, and passes many requests through a multi-threaded queue for processing because it "knows" certain actions have to run on STA threads, etc.

While its convenient, it concerns me that this one type knows so much about how everybody else in the system is designed. I'd much prefer a more generic hub that can be given instances which can expose events or methods or callbacks or that can consume these.

I've been seeing more about the IObservable/IObserver features of the reactive framework and that are being rolled into .NET 4.0 (I believe).

Can I leverage this pattern to help replace my "god object"? How should I go about doing this? Are there any resources for using this pattern for this specific purpose?

Answer 1

It would appear that you can replace your god object with what MSDN describes here:

To create complex event processing (CEP) applications using the Microsoft StreamInsight platform, you create structures that define the events, objects that produce and consume the events, and query templates that contain the business logic needed to process the events.

Our team is not moving to .Net 4.0 any time soon (unfortunately). So we circumvented a god object scenario by building a custom framework akin to what MAF/MEF provides. This created a distributed knowledge base using what Microsoft calls an adapter. Each adapter is only responsible for it's own module, passing data, events, etc. There is a common operator that receives the data and events, processes, and passes back to the respective adapter.

My understanding of IObservable & IObserver lends me to believe that a god object will not be necessary - in effect creating a distributed knowledge base of what is going on within the different parts. An apparent advantage to these interfaces also seems to be that the intermediate communicator (i.e. the adapter) is no longer required. So the distribution of knowledge is really in the IObservable derived class. This model inherently derives a talker/responder relationship - no mediation/arbitration class.