I am having problms with the observer pattern. It says Observer and Subject should both be interfaces. I see why observers are interfaces, but why isn't it better to have the subject an abstract class? Couldn't you already implement al least remove/register?
5 Answers
Design patterns are meant to be adapted to the particular needs of the applications; they don't prescribe rules set in stone. In particular whether something is an abstract class or an interface is for you to decide, considering all the implications that the decision has for the rest of the application.
That said, interfaces are recommended over abstract classes in general for several reasons. For example abstract classes require you to use inheritance, and in many languages you can't inherit from more than one class. If that's not a problem for your use case, go ahead and use abstract classes if you find them more convenient.
1 Comment
supercat
In many ways, the ideal pattern would be to have an abstract class which implements an interface, but never define any storage locations of the abstract class type--always use the interface. That would allow classes which can derive from the abstract type to simply inherit useful code, while those which must derive from other types could import any common code as boilerplate. The approach will fail, however, if some consumers of the type use the abstract type rather than the interface type, even though that shouldn't be necessary unless classes need to access other instances' private data.
Why not just have an abstract class that implements Subject? Using interface just gives you greater flexibility. It doesn't really buy you anything to start with an abstract class. If things every change a great deal (say crossing process boundaries) then your Observable will be stuck with the abstract implementation.
Comments
In a design pattern when the word interface is used, it means the abstract API that is exposed to client component that will have different concrete implementations.
When design pattern interface maps to Java world, it could be either Java interface or a Java abstract class, and design pattern concrete class maps to a Java regular class (non-abstract).
However when making a decision you do need to understand difference between Java interface and abstract class and their purpose as well as pros and cons.
Comments
why isn't it better to have the subject an abstract class
To avoid tying the design to a particular concrete implementation. Remember the purpose is to create a pattern that will give you the flexibility to swap concrete subjects as needed and not have the observers tied to whichever original implementation there was.
You do not want the observers to reference a FirstConcreteSubject, but rather an interface ISubject, which can quickly be changed to be implemented by a SecondConcreteSubject without the need to modify the observers.
That said, there is nothing wrong (IMHP) with having a BaseSubject abstract class to store some of the code that would have been otherwise duplicated by FirstConcreteSubject and SecondConcreteSubject.
Comments
Java interfaces describe types (as defined by the book, Design Patterns). The limiting factor in Java interfaces is that you can't declare an instance variable needed for your list of observers.
That is where abstract class comes in. You can declare an instance variable like this:
import java.util.List; public abstract class Subject { List<Observer> observers; // this would not be allowed in an interface public void attachObserver(ObjectObserver objectObserver) { // implementation }; public void detachObserver(ObjectObserver objectObserver) { // implementation }; public abstract void notifyObservers(); } However, interfaces are better, because they are better at forcing encapsulation. You could add another layer of abstraction by declaring the three methods in an interface that in turn declares those methods/"types". Then the abstract class could implement those methods.
