Tags

, , ,

In OOP, but most in general in Software Engineering, decoupling is an important concept to keep always in mind.  We can think about coupling as the degree to which each object (or program module) relies on each others.

In “The Pragmatic Programmer“, the authors, after mentioning that “Good fences make good neighbors”, recommend to write “shy” code.

Shy-code? Almost funny to hear, although, if fully understood, it’s a powerful concept, which makes clear the idea of decoupling. They say that “shy” works two ways: don’t reveal yourself to others, and don’t interact with too many people. Isn’t this a shy personality? 🙂

In order to write shy-code, we should organize it into cells and limit the interaction between them. Here, the authors wisely use the word “limit” instead of “remove”, because, of course, interaction between objects is a basic and important concept that cannot be removed. Objects need to interact in order to perform their tasks.

So, the point is, how can we design systems where objects interact each others, but where coupling is kept at the lowest possible level? Of course a lot come from experience, but, also with a lack of experience, there are different best practices or design patterns which help us to achieve good results. One of these is, undoubtedly, the Observer Pattern.

The Observer (or Publish-Subscribe) is a Behavioral Patterns used to maintain consistency between related objects, without making the classes tightly coupled. It is mainly used to implement distributed event-based systems, and it is also an important part in the Model View Controller (MVC) pattern, where the View has to observe changes into the Model.

This is the kind of pattern to keep in mind when designing system, because it is so simple, but yet so powerful. And  we do love powerful but simple stuff, don’t we? 😀

Following is the UML class diagram which shows the pattern’s participants:

the observer UML class diagram

We have an abstract Subject, which knows its observers and provides and interface for attaching and detaching Observer objects. On the other side, we have an abstract Observer, which defines an update() method used to notify changes in a Subject.

The two abstract classes are respectively extended by a ConcreteSubject, which stores state of interest to the Observer objects and sends a notification to its observers when its state changes. And by the ConcreteObserver, which maintains a reference to a ConcreteSubject object and implements the update() method to keep its state consistent with the subject’s one.

The notify() method will perform something like that:

// Subject class
for(Observer o:observers){
    o.update();
}

Whilst the update() method will request the new state to the ConcreteSubject:

// ConcreteObserver class
observerState = subject.getState()

If you are a Java developer, you probably know that java.util provides us the pattern through the interface Observer and the class Observable.

Although Observer is an interface, Observable is neither an interface nor an abstract base class: it is a concrete class. This is very weird! At first glance, we could think that this is done to allow us to use composition instead of inheritance. But, having a look at the source code, we can see that is not possible, because there is an internal flag:

private boolean changed = false;

That is checked everytime the notifyObservers is invoked:

public void notifyObservers(Object arg) {
        Object[] arrLocal;

    synchronized (this) {
        if (!changed) return;
            arrLocal = obs.toArray();
            clearChanged();
        }

        for (int i = arrLocal.length-1; i>=0; i--)
            ((Observer)arrLocal[i]).update(this, arg);
    }

So, from a composed class, we would not be allowed to change this flag, since it is private, and the methods provided to change it are protected. This means that we are forced to extend Observable! Therefore, at least from my point of view, the choice of a concrete class in this case remains a mystery!

And what’s your opinion? 🙂

Advertisements