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.
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.
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.
See: Interface Vs Abstract Class
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();
}
How does the Observer pattern reduce coupling?
The Observer Design Pattern is a way to design a subsystem that allows many objects to respond automatically to changes of an object that’s being observed. The Observer Design Pattern is also known as the Event-Subscriber or the Listener pattern.
Do you agree if coupling reduces in above mentioned example?
I agree that observer pattern reduces coupling among its participants because it introduces an abstract type, Observer, between the Subject and its Observers. The Subject updates an Observer with some information and doesn’t know about the Observer’s implementation.
This characteristic gives us flexibility. This pattern allows us to add and remove Observers at any time, so, you do not need to modify either Subject or Observer for it.
Source: Stackoverflow