The observer pattern allows for the creation of one to many dependency relationships that notifies all the observers about a state change in the subject automatically. Below is a generic UML diagram taken from the CS3219 slides titled Object Interaction Patterns (credits: Prof Bimlesh Wadhwa).

In the diagram above, we can see that the Subject abstract class allows for observers to be added or removed at any time using the attach or detach method. This is particularly helpful when we constantly need to add or delete observers. All the observers of a subject can also be notified automatically when the state of the subject changes using the notify method. Each observer then updates its behaviour accordingly. Depending on the implementation, the subject may “push” information to the observers, or, the observers may “pull” if they need information from the subject.

Let us now look at a more concrete example. The observer pattern can be exemplified by Instagram. Let us say that the subject is a celebrity or an influencer. The celebrity (subject) will post about things (updating their state) and all their followers (observers) will get a notification (through the notify method) about the celebrity’s post. Any Instagram user can follow (attach method) or unfollow (detach method) a particular celebrity at any time and hence the list of observers is constantly changing.

In the sequence diagram above, we can first see two users who follow a celebrity (i.e. attach themselves as observers to the subject celebrity). Then when the celebrity or subject’s state changes (maybe adding a new social media post), it calls notify on itself which in turn triggers the update method for all its observers. The observers (or users) then get the updated state of the celebrity object — are now able to see the post of the celebrity on their feed. More users are able to become observers (by calling attach method) or current observers such as user1 and user2 can stop following (or observing) the celebrity by calling the detach method. Again, depending on the implementation, the subject may “push” information to the observers, or, the observers may “pull” if they need information from the subject.

To summarise, the observer pattern is great to achieve event driven triggers and allows for the list of observers to change easily.

This pattern involves a single class which provides simplified methods required by client and delegates calls to methods of other components/subsystems and returns the final result to the client. It is called a façade as much like façade in architecture, the client does not know about what goes on after calling the façade layer (complexities are hidden). Let us now see the façade pattern in action in the context of Amazon.

In the diagram above, we see a user placing an order through the Amazon application on his or her mobile phone. A naïve implementation would be for the mobile phone application (or mobile client) to handle all the interactions with the subsystems such as paymentGateway, warehouse and shipping. However, this is quite complicated and we wish to ‘hide’ all these complexities. Thus, we can employ a façade pattern similar to the one shown in the diagram above.

As seen in the diagram above, the mobile client simply has to send the order and payment details to the façade and wait for the façade to return the order confirmation with the expected date of arrival for the order. The mobile client is not aware of the complex calls that the façade is handling (calls made to paymentGateway, warehouse and shipping) and it does not need to be aware of all these calls.

The façade layer will make multiple calls on behalf of the mobile client. Firstly, it calls paymentGateway to ensure that the payment transaction is successful. Once the transaction has been completed it contacts the warehouse component to check where is the nearest warehouse location that the item is found and the warehouse component returns the details of the nearest warehouse location back to the façade layer. The façade layer can then call the shipping component and get an estimation of how long the delivery might take. Finally, after making these 3 calls, the façade layer will return the combined result — confirmation of the order along with the expected arrival date of the order.

The advantage of façade pattern as seen from the diagram above is that it provides a single endpoint for the mobile client to call and it is very easy to use. There are many advantages to the façade pattern. It allows the mobile phone application developers to work independently of the paymentGateway, warehouse and shipping components and they do not need to be concerned about making multiple calls.