CODEWITHSUNDEEP
c#design-patternsobserver-pattern
Emerion
Emerion

Reputation: 810

C# Observer pattern: Still tightly connected?

ok, so I am stuck at the observer pattern here, almost all tutorials I read tell the subject class to subscribe the observer(s).

But with encapsulation in mind, how is this not tighlty coupled? They still depend on each other know, don't they?

What I mean to say is that the subject Class must know the observer object to add him to the list of objects to notify.

Therefore a dependency is created, right?

What's the mistake I make?

Thanks!

Thanks everybody for the replies,

Now I have some new questions. If I understand correctly the best way to deal with this is with Interfaces. So I will do that ;)

But, Why are the always talking about delegates and events? events ARE a form of delegates. So why aren't they just saying events?

Upvotes: 1

Views: 808

Answers (7)

explorer
explorer

Reputation: 12090

You ask "Whats the mistake I make ?" . Your following line is where I think you went wrong:

What I mean to say is that the subject Class must know the observer object to add him to the list of objects to notify.

Upvotes: 0

testalino
testalino

Reputation: 5658

The class that is Observable can accept interfaces in the observe method. This interface is defined in the library where the subject Class is defined and then implemented by the subscriber. That way, the classes only know what they are supposed to know.

Upvotes: 2

El Ronnoco
El Ronnoco

Reputation: 11922

All the observer object and the observed object know is that they are interacting with an IObservable and an IObserver object respectively. The exact type of these objects is irrelevent to them - they only care that they implement the IObserver and IObservable interfaces.

Upvotes: 0

Lasse V. Karlsen
Lasse V. Karlsen

Reputation: 391396

When you say "know", you're right that the publisher must know about the observer in order to publish information to it.

However, it doesn't need to "know" about it in the sense that it is hardcoded that:

  • The observer is always going to be this particular class
  • There is always going to be these particular observers available

In its basic form, events are publisher/observer in play, so you can easily do this just with events:

public class Observer
{
}

public class Publisher
{
    public event EventHandler SomethingHappened;
}

You would then make the observer handle that event:

public class Observer
{
    public Observer(Publisher pub)
    {
        pub.SomethingHappened += Publisher_SomethingHappened;
    }

    private void Publisher_SomethingHappened(object sender, EventArgs e)
    {
    }
}

public class Publisher
{
    public event EventHandler SomethingHappened;
}

Whenever this event is raised from the publisher, the observer is informed about it. Realize that the act of hooking into an event is to "tell" that class about the observer, but the publisher doesn't have any hardcoded information about the publisher, except that there is someone out there listening.

A different way would be using interfaces:

public class Observer : IObserver
{
    public Observer(Publisher pub)
    {
        pub.Observers.Add(this);
    }

    void IObserver.SomethingHappened()
    {
    }
}

public class Publisher
{
    public List<IObserver> Observers { get; private set; }
}

public interface IObserver
{
    void SomethingHappened();
}

Again, the publisher will "know" about the observer in the sense that it has a reference to it, but again it has no hardcoded information about which class or how many instances there will be.

Just a word of warning: The code above is very flawed, at a minimum you should ensure that the observer "unhooks" from the publisher when you're done, otherwise you're going to have leaks in the system. If you don't understand what I mean by that, leave a comment and I'll edit in an example.

Upvotes: 4

Lazarus
Lazarus

Reputation: 43084

I think you have read this slightly wrong, yes, the subject does subscribe the observer but it doesn't initiate the subscription, i.e. MySubjectClass.Observers += MyObserverClass;

By using an interface to define the contract between the Subject and the Observer you allow the Observer to be any class that implements the interface.

So you can see this is not tightly coupled, i.e. the Subject isn't instantiating concrete Observer classes.

Upvotes: 0

Thomas Weller
Thomas Weller

Reputation: 11717

An observable object in C# is an object that declares one or more events. One or more observing classes might or might not subscribe to these events at runtime. The observable part does not know and does not care.

The observed class does not have to maintain a list of objects to be notified. It just has to fire an event and otherwise is totally agnostic about who is listening.

So there's no dependency whatsoever from the observed class to the observing one. Only the observing one has to know about the events that it can observe.

Thomas

Upvotes: 1

Euphoric
Euphoric

Reputation: 12849

I dont really understand you. But if you are worried about Observer pattern in C#/.NET. Then developers at Microsoft already solved all your problems in form of events.

Upvotes: 0

Related Questions