Is it still an observer pattern without the interfaces for observer and subject? Here is an example I'm not sure about

Question

I'm learning object oriented design patterns, but don't see why this is not the observer pattern if I only have concrete listener and subjects. In my practice example I have created a DMV office scenario with a single subject called the DmvCounter and Customers (the observers). In my main method, the customers are constructed with the task they would like the DMV office to complete for them.

Customer bob = new Customer("Bob", "Register Vehicle", 201); // number is bob's order
Customer pat = new Customer("Pat", "Renew License", 202);
dmvObject.register(bob);
dmvObject.register(pat);

dmvObject.handleRequest(200); // nothing happens - no customer for this request number
dmvObject.handleRequest(202); // prints: "Pat says: Thank you - Renewed License"

My question is the above is an interprocess communication between 2 objects only. No Interface for observer, and no interface for subject. Subject notifies it's list of concrete customers of a particular order number that has been completed.. And the customer leaves the DMV office satisfied. Is this not the observer pattern?

Answer 1

This is an example of the Observer pattern.

In a typical Observer implementation, the subject maintains a list of dependents and notifies those dependents by calling a method on each of them. That's the situation you have described.

Now, you could make the argument that this isn't a particularly useful implementation of the Observer pattern, because the Observable object needs to not only know what type of object is observing it, but needs to know the method signature of the observing object. This isn't particularly extensible because DmvCounter can't be observed by anything other than a Customer .

The benefit of implementing an interface (like java.util.Observer ) is that you can add any variety of observers without needing to change DmvCounter , and all can be notified using a single method update(Observable o, Object arg) .

Answer 2

The idea of design pattern sticks with the idea of OOP, therefore every design pattern must contain as many concepts of OOP as possible. You have to understand the concept of OOP before moving to design pattern, otherwise it would be quite confused.

So why we need interface? The answer is for polymorphism.

Imagin that you have another customer, say customer2. Then in your DmvCounter, you have to implement all the functions for customer2 like this:

public class DmvCounter() {
    List<Customer> customer = new ArrayList<Customer>();
    List<Customer2> customer2 = new ArrayList<Customer2>();

    public void register(Customer customer) {
        //do something
    }

    public void register(Customer2 customer2) {
        //do something
    }

Now imagine you have 100 type of customers, and with each type you do exactly the same job for register. If you have to implement the register code 100 times, it would be an extremely time-consuming and painful task. So the idea of polymorphism is: whatever type of consumer is, it is still a consumer, and you just need 1 register function for that.

So to answer your question, yes it is still a kind of observe pattern. But it is not an observe pattern, because it doesn't meet the requirement of OOP, which is polymorphism