Design patterns are useful tools but complex, so it should be known when to use them in a natural way.
These concepts were born in the architecture field to identify those patters buildings used to have and later in 1995 came to the software world solving limited and generic problems. So if there is a specific issue or not limited then it is not recommended to use design patterns.
Conclusion: the main goal of design patterns is to solve limited and generic problems, let’s say they are the template a problem has: the issue itself, its solution, and the examples.
Following the book published in 1995 “Design Patterns”, in language programs there are three different categories:
• Creational Design Patterns, in JavaScript it would be the constructor function. From a complex object, it derives others.
• Structural Design Patterns. In JavaScript, it would be the proxies and their task is to add obtain new functionalities to the class or object without affecting its structure.
• Behavioural Design Patterns in JavaScript, it would be the observer, and its job is to be concerned about the communication among dissimilar objects.
Singleton Patterns allow us to solve two actual problems: a class that creates only one instance and makes it accessible globally without getting modified by the client-side.
To make this the singleton class will have a private constructor, this will make the instance be global but not modifiable; it will have a method “getInstance()” to create the new instance if it doesn’t exist first or to reference to the existing one.
An example of this pattern is when getting data from a database like Moongo, here we want all the objects to interact with the same iteration and nor creating new ones all the time the data is called, also this data is important so it should be unmodified.
As we commented before the basic structure of the c singleton class is to initialize inside a private static instance and a private constructor. The only public access to the class will be the method** getInstance()** that will initialize the instance if it doesn’t exist or return the existing one.
An example below:
/**
* TheSingleton class defines the `getInstance` method that lets clients access
* the unique singleton instance.
*/
class Singleton {
private static instance: Singleton;
/**
* TheSingleton's constructor should always be private to prevent direct
* construction calls with the `new` operator.
*/
private constructor() { }
/**
* Thestaticmethod that controls access to the singleton instance.
*
* This implementation let you subclass the Singleton class while keeping
* just one instance of each subclass around.
*/
public static getInstance(): Singleton {
if (!Singleton.instance) {
Singleton.instance = new Singleton();
}
returnSingleton.instance;
}
This pattern design forms part of the behavioral category, the problem is simple: a bunch of objects called subscribers or observers is linked to a publisher or subject through a subscription method and when this subject presents a change or new event, this through the link will notify the subscribers randomly. Also, it must be possible to break the link unsubscribing.
Here we have a class publisher, which is the subject subscribers observe. This must count with an array where it does store the subscriber’s list and both methods subscribe and unsubscribe. About the subscribers, this must count with the same interface, that when receiving the notification from the subject, the update method will update the object.
This pattern is very used nowadays to send a notification when one subscribes to a newspaper for example. Its excessive use can saturate or stress the subscriber tending it to unsubscribe.
Here is important to specify two interfaces, that are the structure logic the class will have. In the case of the subject, this will contain the property of the state, which means if it is changed or not, then the array of subscribers will be private. As methods it will contain the subscribe(), unsubscribe() and notify() methods.
On the side of the observer, this will count with the receiver method,update() that will catch the notification. Finally, when creating the instances of the subscribers it should subscribe through the method subscription of the subject.
Redux is a library used frequently by React or angular that notify to the subscribers the change of state of the Application, through actions that trigger a method reduce() that will get two parameters the old state of the App and the dispatch(), an action that changes the state and compare both states to finally notify the subscribers. This system avoids the modification of the state directly. It’s just through a process where we can listen to that change.
An example is the YouTube App where we have a system of videos that will receive updates, the dispatch actions, and the app must notify the subscriber of the new videos through notifications.
This structural pattern looks to add new functionalities or behaviors of the object dynamically without altered it.
It looks like subclassing in JavaScript the problem is each time a new class is created with a different functionality, it will derive to a chaotic code and non-understandable. The solution this pattern brings is to wrap the objects inside a object decorator so when that object with a new functionality is called this wrapper will be the one of adding that new feature to the base object.
So an example in Typescript using this pattern is when we have an input object and it is wished to required the field and email, these two are different new functionalities.
It starts with the base object that is the input, this count on an error array for the new plugins, a empty method through all these functionalities will be linked. After the object is called with the empty method and validated, to add the new code inside that method. If it is wanted to add more functionalities then the last version has to be called validated (this recognise the last object) and then add the new code in the method to be pushed in the array.
