In the previous article, we had a look at design patterns, its definition, history, and the incorporation into software engineering. This article focuses on a creational design pattern, a type of design pattern in software engineering. Creational design patterns are used to create new objects. When a new object of some type is to be created, there are several design patterns to be considered. Let’s start off with the Constructor Pattern.
1) A brand new object is created.
2) It links that object to an object prototype.
3) It binds the ‘this’ keyword to the new object scope.
4) And then returns ‘this’.
ES6 brings the ‘class’ keyword to
desugar creation of objects but it finally transpiled to the prototypes.
So the above codes are pretty much the same. Just that using classes make the code quite familiar for developers coming from class-based languages like Java, etc.
Constructor Pattern helps to new up objects using the new keyword
Module Pattern at its core is an object literal that simply helps to encapsulate a group of like methods. Mostly, the Module Pattern acts as a service. For instance, we can have a service for database calls or services for my HTTP calls. Every time you want to do something with the database, you call this database module to deal with all of my database calls.
In this case, we are creating a module as a variable that's just an object with a couple of methods on it, get and save. But they're key values, so in order to execute a method you do moduleName.methodName and that's going to execute that function. Hence, the Module Pattern is just a collection of keys and functions.
But we can do more interesting things with this when we wrap it in a function, we can start doing all kinds of fun things like creating private variables sitting inside the module. With Module Pattern, we get only one of the modules created, unlike the Constructor Pattern where we can create a bunch of them by always "newing" things up.
Module Patterns can be expressed in many variants. The above code for the Module Pattern can be rewritten to The Revealing Module Pattern, which looks like this.
Usually, the Constructor Pattern is used any time we want to have multiple objects since we can easily new up objects. A constructor function is needed to new up these new objects. The function helps to initialize data members and to establish class invariant using values passed into the constructor. For everything else, like configuration, an open connection to a database, setting up caching, etc., the Constructor Pattern becomes inappropriate. This is where the Factory Pattern comes to the rescue.
Factory Pattern is used to simplify that and hide a lot of complications from the from our frontend.
In the above code, a factory object is exposed to the client to interact with three different types of repositories with each implementing get and save method. The client does not have to know how these repositories were created.
The last pattern we're going to talk about is the Singleton Pattern. The Singleton Pattern is used to restrict an object to just a single instance of that object across your entire application. With a singleton, it remembers that the last time an object was created so instead of creating a new object, it makes use of the existing object. Now that we know how single patterns work, let us write a sample code for that.
We have gone through Creational Design Patterns, patterns for creating new instances of objects. First, we talked about the Constructor method for creating instances of an object when newer we want a new instance of that object.
We also had a look at the Module Pattern, which is used when you want to bundle a group of like things together and create just a bundle of methods.
Also, we had a look at Factory Patten for creating instances of different objects without allowing the client to know how the object was implemented. And the last we talked about is the Singleton Pattern which helps to restrict and object to just a single instance of that object across your entire application