Creational Design Patterns
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.
Constructor Pattern
The Constructor Pattern is not originally from the Gang of Four. But as we construct new objects in JavaScript, it is really important to know more about this pattern. The constructor pattern is used to create new objects with their own object scope. JavaScript’s object system is based on prototypes, so with Constructor Pattern, the ‘new’ keyword is used to create objects from a function. This is achieved by placing the keyword ‘new’ in front of a function. Hence anytime this keyword is put in front of a function, it creates a constructor function. When this constructor function is executed, there are four things that happen.
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.
TakeAway:
Constructor Pattern helps to new up objects using the new keyword
Module Pattern
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.
Factory Pattern
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.
Singleton Pattern
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.
Conclusion
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
Top comments (10)
As an engineer who uses JS daily, these patterns are often lost in popular framework conventions of today. I love that you're teaching them in a really clear, applicable way. Great post! Thanks for writing it, Mr. Mensah!
It's awesome that you love it, Mr. Garofalo
Nice summary. I'd say that your "Module pattern" is more of a Facade, but that's more of a personal preference... the label is immaterial.
I think I see a bit of a problem with your Singleton. A true Singleton is supposed to guard against accidental creation of multiple instances of the singleton. From what I see in your example code, it seems that someone could accidentally do "new TaskRepo()" and create a second base to then make use of another singleton instance. From what I know of JS, it's almost impossible to stop the construction of an instance... but I could be wrong. (Please tell me I'm wrong and potentially fix your example and prove me wrong :))
I really, really liked your description of the Constructor pattern! It makes a generally confusing concept extremely clear (to me at least), and that was something that I struggled with a lot when starting JS.
Thank you, Mr. Miller, for the feedback, I appreciate that
Since Facade wraps a complex system to expose a simple API for the client to interact with the System, it might be confused with the Module Pattern, which also serves as a wrapper. But the Facade design pattern is often used when a system is very complex or difficult to understand because the system has a lot of dependencies. So it hides the complexities of the larger system and provides a simpler interface to the client. I will talk about the Facade Pattern when I write about the Structural Design Pattern, so let's stay in touch.
Also, about the Singleton Pattern, it was a mistake so I could create multiple instances. I have updated that by wrapping in IIFE. If you any other means of attaining that in Vannila js let me know. For Node since it uses CommonJs pattern it creates singleton anytime we load an instance of any module.
Thanks that was useful (thumbs up)
Thanks Oliver for your nice breakdown of the patterns. As a newbie to JS this is very helpful. I'd also love if you included common use cases for each pattern.
Is it me or the singleton pattern is embedded twice? Once in the Singleton Pattern section and once in the Constructor Pattern?
From my end they are different but the constructor has two different codes; one using prototype and the other using classes
Hey Oliver,
thanks for your work,
I appreciate it.
Welcome. I am happy you appreciate and like it.