2

Sometimes I read in observer-pattern descriptions, to make the constructor of a observer base class protected so the class will be abstract. but by making the constructor public (if even one is neccessary), I could use the observer as an instance and not only as base-class.

Is there any disadvantage of doing so i'm not mentioned yet?

  • An abstract class, by definition, cannot be instantiated. So either you want it to be an abstract class, or you don't. – Robert Harvey Dec 16 '13 at 22:10
  • i don't. i leave the constructor public. sorry bad english, edited the text :) – itwasntpete Dec 16 '13 at 22:11
4

The idea of the Observer pattern is to allow an object to register for updates from another object, without the other object having to know about the actual type of the observer.

In statically typed languages such as Java or C++, this is done by having the class of the object that needs to register for updates, inherit from the Observer class or implement the Observer interface. This is so it could be regarded as an Observer and register as an observer to any class that allows this, without that class knowing about the actual type of the registering observer.

The class allowing objects to register for notifications (called 'the subject') provides a public method registerObserver(Observer o), and thanks to Polymorphism any class that inherits from the Observer class or implements the Observer interface can register.

The Observer class or interface will have a method notifyObserver(), which the subject can call on all the observers registered to it - again, without caring about their concrete type.

This shows you that it makes no sense to instantiate an Observer on it's own. And this is why you define the Observer class as abstract, or in single-inheritance languages as an Interface.

Also, keep in mind that in single-inherited languages such as C# or Java, it's much better to define an Observer interface, and not an Observer class, because if a class inherits from Observer it can't inherit from anything else which is very limiting. However some single-inherited languages support Interfaces, so your classes can implement an Observer interface while still being able to inherit from another class.

Another thing to remember is that conceptually, a class defines an object's type while an Interface defines what an object can do. All your subject cares about is that objects can observe it, it doesn't care what they are. So conceptually an Observer Interface is a better option than a class (unless you use a language like C++ which doesn't have Interfaces but has multiple-inheritance).

1

Assuming you did make the Observer class just another standard class and created a new instance, what would you intend to do with it then? An observer without any behavior is a rather useless object.

Any logic specific to what you are observing would end up in a subclass anyways (i.e. MyEventObserver) and anything that would be generic enough to be used by all observers would be best served in a base class such as an abstract Observer class.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.