When you write Data Validations, Credit Card Validations, Phone Number Validations, and String Validation, we mostly choose 3rd party Common Utilities, mainly the library from Apache. This is to prevent the wheel reinvention; technically we call it “CODE REUSE” or just “REUSABILITY.” When it comes to Design Patterns, the way I think of it is, it’s  still “REUSE,” but to be specific its “EXPERIENCE REUSE.” Why deal with a complex solution implementation go through all the pain? Why not just implement something which has already handled gracefully by engineers who faced a similar issue?  Design Patterns apply to any arena, and we are going to look into the very popular Observer Design Pattern in the Java world.

 when you have to shoot-dont talk-1

What is my use case to go for this Pattern:

Okay, Tuco! Imagine you own data that the world needs badly. Could be Stock Prices, Gold Rate, Exchange Rate, Weather Alerts, Oil rate or YouTube Channel Update (believe me, YouTube is a lot of money.) You need to let people know that you have an update for them, but only to those who are interested (Subscribers AKA OBSERVERS), and technically we call the provider (in this case the DATA owner) as SUBJECT.       In Object Oriented way, we could say that if a set of objects (OBSERVERS) gets informed when there is a change in the STATE of another object(SUBJECT) they ALL are interested.

There is a reason I mention the YouTube Channel as one of the examples. I’m not saying that YouTube implements Observer Pattern, but it’s the best use case that everyone can relate to.

Who are our SUBJECT and OBSERVER now on YouTube?   The Channel Owner is the Subject, and his subscribers are the Observers. This is the data the subscribers are interested about,

   – New Video uploaded   

   – Number of Views on that Video 

   – Response to the comment you posted on that video  

Implementation without Observer Pattern:

My mindset before implementing the design-pattern-less solution; we are not going to rewrite YouTube API here but just throw a sketch of what it might be doing at a very high level.

  video display-API-public void-1

Once the Channel Owner Uploads the video, assume that the video Upload Complete method is called. The new video alert is pushed by calling the update() and in-turn the display() method. 

video upload complete-new vdisplay-public class-1

But where is the logic of maintaining the subscribers? What if I don’t want this update etc. This is what I’m thinking,

        •Create a Subscriber Class

        •Add methods to maintain this list in the YouTube Upload Service class

 dwight-office-listen-I know everything-1

Great! What if we need to push more alerts such as Like Alerts, Comment Alerts, etc. With the current design, it might become a maintenance nightmare. Right now the point is I might start putting more questions against the stability the design I have come up with and embarrass myself, or I can start talking about Observer Pattern and doing things the right way.

Building Blocks of Observer Pattern:

building blocks-oberserver pattern-interface-1

IntelliJ Package Content and UML:

 intelliJ package content-UML-im confused-1

 

Hold On, Almost There:

Here I present the five classes that make the Observer Pattern work.

 5 classes-make observer pattern work-1

5 classes-make observer pattern work-1

 

How this works:

The Subject interface has the following three methods:

          •Register Observer

          •Remove Observer

          •Notify Observer

These methods take care of the subscriptions aka observers, addition/deletion, and notification. The rest of the methods are self-explanatory.

The Observer Interface one method:

  • update

The Observer Interface method does the job. This method is on the receiving end of the notification, and this is where you decide what you do with the incoming payload.

If this is a well justified design pattern don’t we have a Java library that helps us? Why do we need to bring in these features manually? We should assume that the new Java APIs should always catch up with these things right? You are right.

 

Observer Pattern – Java API Util Based Implementation:

Slight change in the script. In the Java API implementation of Observer Pattern, we are going to do  one renaming.

 java-API-implementation-observerpattern-renaming-1

The Subject Interface will no longer be an Interface it will be a Class and will be called Observable. This has a lot of out-of-the-box features. You will see it soon. Good news is Observer Interface is still Observer Interface. 

Notice the util methods that ships in with the Observable class. All you need to do is to extend this class and implement your business. This link explains in detail, https://docs.oracle.com/javase/7/docs/api/java/util/Observable.html

 observable-class-interface-util-methods-ships-1

Code Revamp – Java API Util based – Observer Pattern:

 code-revamp-java-API-observer-pattern-1

Just two classes will do what is needed.

What we achieved here in this pattern is that we kept two interacting objects as loosely coupled as possible and changing one of these objects won’t have a ripple effect on the other. 

Next time (and for sure this scenario will show up), if you need to handle the behavior of a set of objects based on 1 or more objects, STATE, then we should blindly choose Observer pattern. It’s designed to keep your objects of interest on the watch.

I have updated the GitHub with the Harness Test for this implementation. Https://github.com/VinodhThiagarajan1309/design-patterns-headsfirst

Share this:

Leave a Reply

Your email address will not be published. Required fields are marked *