A matter of coupling

Leslie Sanford

I was reading an interesting article[^] in Dr Dobbs on event based architectures. In the article, the author describes an architecture in which objects are almost completely decoupled from each other. This is done through events. Say you have object A that raises an event. Object B is interested in this event. A third party called a binder binds these two objects together without either one of them knowing about the other. This can be easily accomplished in C# using events and delegates.

public Binder()
{
a = new A();
b = new B();

a.SomethingHappened += b.HandleSomethingHappened;

}

However, in playing around with this type of approach, I've noticed that it may not scale well. The problem is that the binder object has all of the responsibility of connecting the dots. This can lead to a ton of configuration code (usually in the binder class's constructor), and it's easy to forget to hook everything up. "Oops! I forgot to hook B to A or was it B to C?" That sort of thing. So I've considered modifying the approach in which each class knows what events it needs to hook to; it does so by taking an object passed to its constructor and hooking to the relevant events. This approach involves greater coupling. The target of an event knows about the sender. But on the other hand, it relieves the "binder" object of having to know how to hook everything up. All it's responsible for is passing the event raising object to the receiver.

public Binder()
{
a = new A();
b = new B(a);
}

// In B's constructor:
public B(A a)
{
a.SomethingHappened += HandleSomethingHappened;
}

This also has the advantage of giving B the option of making the method responsible for handling the event private or protected so that it's hidden from the outside world. We can minimize the coupling by using interfaces that expose only specific parts of a class's overall functionality. Then only a reference to the interface is passed to the target class thus limiting its knowledge of the event raiser. Thoughts?

Pete OHanlon

If you're interested in loose coupling in your design, I would definitely take a look into Dependency Injection. BTW - what you described initially sounds to me like a variation on the Mediator pattern.

Deja View - the feeling that you've seen this post before.

My blog | My articles

Leslie Sanford

Pete O'Hanlon wrote:

I would definitely take a look into Dependency Injection

I did a search and found Martin Fowler's article on Dependency Injection.[^] Iteresting read. My situation is similar but not exactly the same to that described in the article, but I think the principle is still applicable, more or less. Basically, I have one class that offers a set of services, mainly simple notifications when certain things happen within the application. Next, I have a group of class's that use these services. Which services are used can vary from class to class. The problem I run into is when I start trying to manually wire things up. So I've got my Service over here and my Clients over here, and I have to remember which services a client needs when wiring them together. The solution that I've settled on is to pass the Service to each Client when it is created. Then the Client can subscribe to those services it needs. The containing class, the one containing all of the Clients, doesn't have to know how to hook up Clients to the Service; it just pass the Service along. I think I like this solution. It has greater coupling in that Clients are familiar with the Service, but this can be mitigated by hiding the Service behind an interface, which I think is what Dependency Injection does, more or less. Anyway, thanks for the reply. I'd heard of Dependency Inversion but not Dependency Injection.

led mike

Pete O'Hanlon wrote:

BTW - what you described initially sounds to me like a variation on the Mediator pattern.

You mean this initial statement?

Leslie Sanford wrote:

I was reading

led mike

Pete OHanlon

led mike wrote:

You mean this initial statement? Leslie Sanford wrote: I was reading

:laugh:

Deja View - the feeling that you've seen this post before.

My blog | My articles

Fakher Halim

Leslie/Pete, May be you can solve it by using Dependency Injection framework like Spring.NET. I would suggest a good article Dependency Injection Frameworks - Part 1 - Introduction. That way, the instantiation is taken out of Factories into app.config mappings. If, however, you even want to decouple your data access layer from the changes in database tables and schemas, you may abstract those dependencies away using Entity Framework, example is at Modeling Enterprise Applications with Entity Framework

Fakher Halim

Pete OHanlon

I've already seen your article. There's no need to spam it. :rolleyes: And I've done a lot of Dependency Injection, so I don't need a link to an article on it, hence the reason I recommended it.

Deja View - the feeling that you've seen this post before.

My blog | My articles

Fakher Halim

Pete, May be I was not very clear:(( . Actually not only I agreed with your opinion, but I meant to add into your concise reply by informing Lelie who wrote "I'd heard of Dependency Inversion but not Dependency Injection", that is why I referred to a link! Perhaps it was"Inversion of Control" :( that was intended.

Fakher Halim

modified on Thursday, July 17, 2008 4:00 PM

Pete OHanlon · modified on Thursday, July 17, 2008 4:00 PM

Fakher Halim wrote:

Perhaps you meant "Inversion of Control"

Nope - I meant Dependency Injection, as featured in my original post, and which he found in his search. Anyway, no harm done.

Deja View - the feeling that you've seen this post before.

My blog | My articles

Fakher Halim

Thanks!! it should be just a typo! :-D

Fakher Halim