Have you ever been on a team and you need to start a project from scratch? That's usually the case in many start-ups and other small companies. There are so many different programming languages, architectures, and other concerns that it can be difficult to figure out where to start. That's where design patterns come in.
A design pattern is like a template for your project. It uses certain conventions and you can expect a specific kind of behavior from them. These patterns were made up of many developers' experiences so they are really like different sets of best practices. You and your team get to decide which set of best practices is the most useful for your project. Based on the design pattern you choose, you all will start to have expectations for what the code should be doing and what vocabulary you all will be using.
Programming design patterns can be used across all programming languages and can be used to fit any project because they only give you a general outline of a solution. There are 23 official patterns from the book, Design Patterns - Elements of Reusable Object-Oriented Software, which is considered one of the most influential books on object-oriented theory and software development. I'm going to cover 4 of the design patterns here just to give you some insight to what a few of the patterns are and when you would use them.
Singleton Design Pattern
The main thing you need to know about the singleton pattern is that it only allows a class to have a single instance and it uses a global variable to store that instance. You'll use lazy loading to make sure that there is only one instance of the class because it will only create the class when you need it. That prevents multiple instances from being created. Most of the time this gets implemented in the constructor.
An example of a singleton that you probably use all the time is a state object in JavaScript. If you work with some of the front-end frameworks like React or Angular, you know all about how the parent component's state gets distributed to the child components. This is a great example of singletons in action because you never want more than one instance of that state object.
Strategy Design Pattern
The strategy is pattern is like an advanced version of an if else statement. It's basically where you make an interface for a method you have in your base class. This interface is then used to find the right implementation of that method from one of the derived classes. The implementation, in this case, will be decided at runtime based on the client.
This pattern is incredibly useful in situations where you have required and optional methods for a class. Some instances of that class won't need the optional methods and that causes a problem for inheritance solutions. You could use interfaces for the optional methods, but then you would have to write the implementation every time you used that class since there would be no default implementation.
That's where the strategy pattern saves us. Instead of the client looking for an implementation, it delegates to a strategy interface and the strategy finds the right implementation.
Observer Design Pattern
If you've ever used the MVC pattern, you've already used the observer design pattern. The observer pattern is like the View part of MVC. You have a subject that holds all of the data and the state of that data. Then you have observers, like users, that will pull data from the subject when the data has been updated.
There are so many applications for this design pattern that it became an integral part of MVC. Sending user notifications, updating, filters, and handling subscribers can all be done using the observer patter.
Decorator Design Pattern
Using the decorator design pattern is fairly simple. You can have a base class with methods and properties that are present when you make a new object with the class. Now say you have some instances of the class that need methods or properties that didn't come from the base class. You can add those extra methods and properties to the base class, but that could mess up your other instances. You could even make subclasses to hold specific methods and properties you need that you can't put in your base class.
Either of those approaches will solve your problem, but they are clunky and inefficient. That's where the decorator pattern steps in. Instead of making your code base ugly just to add a few things to an object instance, you can tack on those specific things directly to the instance. So if you need to add a new property that holds the time for an instance, you can use the decorator pattern to add it directly to that particular instance and it won't affect any other instances of that class object.
Have you ever ordered food online? Then you've probably encountered the decorator pattern. If you're getting a sandwich and you want to add special toppings, the website isn't adding those toppings to every sandwich every current user is trying to order. It just adds those special toppings to your instance of that sandwich. When you need to work with multiple instances of an object that need values added dynamically like this, the decorator pattern is a good option.
I used to think that design patterns were these crazy, far-out software development guidelines. Then I found out I use them all the time! A few of the patterns I covered are used in so many applications that it would blow your mind. They are just theory at the end of the day. It's up to us as developers to use that theory in ways that make our applications easy to implement and maintain.
Have you used any of the other design patterns for your projects? Most places usually pick a design pattern for their projects and stick with it so I'd like to hear from you guys about what you use.
Hey! You should follow me on Twitter because reasons: https://twitter.com/FlippedCoding
Top comments (19)
I was hoping for examples but this is great on its own 🤘
you can check them here:
addyosmani.com/resources/essential...
loredanacirstea.github.io/es6-desi...
I love Addy Osmani examples and takes on JS patterns ^ he is my go to guy when it comes to anything JavaScript related (: but I was hoping for more customized examples from the perspective of the writer.
Me too, it could help to visualize the situation
me3
me4
Me 5
MI6
I agree. This post without examples is futile. Please put some effort on your posts!
You could be kinder in your criticism, e.g. offer resources on posts you consider non-futile, or provide examples of what you would consider putting 'effort' into a post. Writing doesn't come easily to everyone, you can't possibly know how much effort the writer put into this.
I'm not being rude, friend. I already got a warning email for expressing my opinion? Don't be so soft, please.
Putting effort is putting actual examples on a daily work routine, not just something copied from elsewhere.
Wait you got a warning email and you weren't rude? Perhaps it was a mistake? I mean you must be correct, being so hard and all...
Perhaps you would consider learning from your mistake and move on? Nope you accuse the author of plagiarism! And without any evidence too, remember no example means no effort, and we wouldn't want so 'hard' person to come along and remind you how without examples of daily work routines you have made no effort at all, would we?
That's ignoring the fact that such a defamatory statement could be considered libel, in some areas of the world.
Read the code of conduct again if you get a moment and consider if your actions have met these requirements. Here is a link incase you hadn't seen it before: dev.to/code-of-conduct
This is a good post but I think it could be awesome if you add some examples. Keep up the great work!
Thanks for offering your perspective of these four design patterns. I didn't realise I've been using the Singleton pattern for Angular and React, nor that I've been using the Observer pattern within the MVC pattern! Looks like I also do use them all the time!
I agree with KristijanFistrek, that examples are great to know in deep, but this post is good without examples also. If you are looking for website design, you can contact our experts
here!
Thank you, it was very good
Im so eager to know more about resign patters specially by real example.
that was great! thank you for sharing
'Design patterns in software' always sounded so high-level and scary - after reading your post, I know that I'm already using and understanding many of them! Thanks for a great article.
Which pattern anyone would recommend to use to create amazon like application using vanilla Javascript or with react (and both) ?
thanks
Some comments may only be visible to logged-in visitors. Sign in to view all comments.