Common Design Patterns in JS
What is a Pattern ?
A pattern is a reusable solution that can be applied to commonly occurring problems in software design. in our case we are using these design patterns in a JS application.
What is the need to use design patterns ?
- Design patterns are the proven solutions to some common problems.
- Avoid code repetition – Certain patterns can actually decrease the overall file-size footprint of your code by avoiding repetition.
Now there are 3 main categories of design patterns –
- Creational Design Patterns – Creational design patterns focus on handling object creation mechanisms. Some of the patterns that fall under this category are: Constructor, Factory, Abstract, Prototype, Singleton and Builder.
- Structural Design Patterns – Structural patterns are concerned with object composition and typically identify simple ways to realise relationships between different objects. Patterns that fall under this category include: Decorator, Facade, Flyweight, Adapter and Proxy.
- Behavioural Design Patterns – Behavioural patterns focus on improving the communication between objects in a system. Some behavioural patterns include: Iterator, Mediator, Observer and Visitor.
As this will be a quite big article we will be focusing on Creational Design Patterns onlyin this blog. Structural and Behavioural will be explained in the part 2.
Creational Design Patterns
We will discuss about Constructor, Module and Factory pattern in this section, as these 3 are most commonly used patterns throughout the software development.
Constructors are used to create specific types of objects – they both prepare the object for use and can also accept parameters which the constructor uses to set the values of member variables when the object is first created.
Refer the following example –
Main problem with this is that every time we create a new object from Car, the getType function gets re-initialised each time. So to overcome this issue we can use prototype method to make it more efficient.
Constructor Prototype Method –
Here, a single instance of getType() will now be shared between all of the Car objects.
A new instance of the class is created if it doesn’t exists or return the reference to that object if the instance is already present/exist.
In this, we have added our own private and public methods and exposing only those which you wish to make public is quite straight-forward.
Use – it’s quite useful when exactly one object is needed to coordinate patterns across the system
Module Pattern (Encapsulation)
Two characteristics of a classic module pattern:
- There must be an outer wrapping function that gets executed, it does not have to be an IIFE.
- There must be one or more functions that needs to be returned from the function call, one or more inner functions that have a closure over the inner private scope.
With this pattern, only a public API is returned, keeping everything else within the closure private. Variables in JS cannot be made public or private technically, so we use function scope to emulate this effect.
Within the module pattern, variables or methods declared are only available inside the module itself thanks to closure. Variables or methods defined within the returning object however are available to everyone.
resetCounter can access
There are some pros and cons of using a module pattern –
- It’s a lot cleaner for developers coming from an object oriented background.
- It supports private data.
- As you access both public and private members differently, when you wish to change visibility, you have to make changes to each place the member was used.
- Private methods added to the the object at a later point can not be accessed.
We use this pattern so that we don’t have to create object using constructor method (new).
It allows us to create objects by only specifying the type and content of the object. We don’t need to specify the exact class of object being created.
Factory Pattern suggests defining an interface for creating an object. We create object without exposing the creation logic to client and the client use the same common interface to create new type of object.
Thank you for reading 🙂
Thats all for part 1. We will be discussing other two patterns and their examples in part 2.