Design Pattern

State Pattern is a #Design Pattern which allows an object to alter its behaviours based on its internal state changes. It is not possible to establish such operations without the design pattern due to the immutability of a running object. By following the design pattern, the object could be able to change its behaviour according to the state change during its lifetime and be extended with new states without affecting the existing states.

Singleton Pattern is a #Design Pattern that ensure a class has only one instance and can be accessed globally. This could be done by having the class to track its sole instance and guarantee that no other instance can be created even when requested. The access should be done in class operation.

Observer Pattern is a #Design Pattern that could be used to implement #Views utilising the Publish/Subscribe Protocol. It is rather useful at decoupling# the presentations of the data from the data itself. There are two objects in this pattern: subject and observer. Observers don’t need to know each other’s existence, but depends on the subject. When there is a change happen in subject, the subscribed observers need to be notified to synchronise the change. This either done in subject to notify all observers that it keep track of (broadcast), or making it the observer’s responsibility to trigger the update when it is needed (centralised or peer-to-peer).

Null Object Pattern is a #Design Pattern where an object explicit neutral behaviour and/or default values. It is usually useful to introduce it by extends (or inherit) from an object that could have a null case. Instead of relying on checking whether the object is null or not, we can create a Null Object and check its behaviour. It simplifies the codebase and apparently a great tool for #Refactoring.

Mediator Pattern is a #Design Pattern that encapsulates and localise how a set of objects interact with each other, especially the collective behaviour. A Mediator object can be seen as an intermediary between objects or hub of communication where they interact with each other indirectly. In this way, we could make changes to their behaviour independently without increasing coupling# between them. The reason is that with Object-Oriented Programming (OOP), we tend to have multiple objects that interconnected to each other (dependencies), which cause a change in one might affect others, thus the coupling between them can be too tight.