File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes OO, Patterns, UML and Refactoring and the fly likes Intepreting the Observer pattern Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Intepreting the Observer pattern" Watch "Intepreting the Observer pattern" New topic

Intepreting the Observer pattern

Alain Utrillo

Joined: Mar 12, 2012
Posts: 2

I have some difficulties to read Class Diagrams given with the Pattern of the GOF.
Most with the meaning of relation that link Classes or Interfaces.

Somebody could explain me the meaning of the links (association, realization ...) in a Class Diagram of the Observer Pattern (see attached to this post).
I could not figure out what does the link between the two interfaces means.
What i want is a sentence in English language that explain me precisely with no ambigous terms.

Thank you for your help

[Thumbnail for ClassDiagram_ObserverPattern.jpg]

Matthew Brown

Joined: Apr 06, 2010
Posts: 4543

Hi Alain. Welcome to the Ranch!

I've moved your post to a new topic, as it's more likely to get answered that way. Here's my attempt at precise an unambiguous (no promises!).

The link from Observable to Observateur means that each Observable object can hold references to Observateur objects. These references are set up using the ajouyObservateur() method, and the Observateurs will be notified whenever the notifiersObservateurs() method is called.

Of course, this will end up as a concrete observable holding references to concrete observers. But the point of the Observer pattern is that the observable doesn't know anything about the observers, except that they can be notified, which is why they reference the interface. The observers add themselves to the observable, and then wait for notifications.

Does that help?
Mohamed Sanaulla
Saloon Keeper

Joined: Sep 08, 2007
Posts: 3152

Looks like the link between Observable and Observateur interfaces is not standard notations. I am guessing that it shows that both the interfaces are associated with each other. I am not sure the association is an aggregation because the notation for aggregation is a diamond (filled or unfilled) at the class which aggregates.

Association would be like one interface makes use of the services of another interface and vice versa.

Mohamed Sanaulla | My Blog
Alain Utrillo

Joined: Mar 12, 2012
Posts: 2
Thank you Matthew and Mohamed for your explanations.
I am sorry for the delay.

I have some questions : (just to be more precise i suppose that we think at the Class level, not at the object level, we could make an instance of this Class Diagram to create a Collaboration Diagram to think with objects but what to do with the 2 Interfaces)
So how an interface could request a service from another interface. As far as i know, An interface could not implements the code in one of its methods, because it's an interface, is it right?
How an interface could create an instance of the other interface, what constructor does it use for that?
Supposing the reference is created in on interface, what can we do with it, we could not invoke any methods from the other interface because the code for this method is not exiting in the interface.
Am i right?

The link (without qualified it as <association> <realization> <agregation> etc) between those two interfaces is a medium to communicate a message (synchon|asynchron), is it right? but i could not understand which information is passing through this link.
I need it to implement the code.

I am sorry it could be borrowing here.
Thank you for reading me.
Matthew Brown

Joined: Apr 06, 2010
Posts: 4543

It's true that an interface doesn't itself contain any code. But what the interface is doing is defining a contract that any class implementing that interface should follow. The fact that Observable has an association with Observateur means that any realizing class of Observable (e.g. ObservableConcret) will have that association. Any class that doesn't implement that association hasn't implemented Observable correctly. This should also be documented in the contract for the methods.

So ObservableConcret will contain a collection of Observateur objects. And remember, although that collection is defined in terms of the interface, the contents will be instances of a concrete class, so calling the methods will not be a problem.

The code could look something like this:

I agree. Here's the link:
subject: Intepreting the Observer pattern
It's not a secret anymore!