I’ve recently found myself spending time reading up on the various design patterns out there, primarily JavaScript based but they can be applied to any language. I found this great free book which provides a good overview of what is possible in JS but it got me thinking. With so many design patterns out there I’ve hit a number of questions such as:
- How should I identify a pattern that best suits my situation, what questions should I be asking myself?
- Should I start out with a pattern for my whole project?
- Is not knowing all of the patterns a bad thing? I feel there is great risk in only knowing a set way of doing things.
- Can I just pick one or two and get quite far through my projects without bad practice?
- How should I document my pattern for others to easily understand the structure of my project and code?
- Is following something better than nothing?
My worry would really be selecting the wrong pattern and trying to force my code and project to match. It would be great to see how other people tackle these decisions.
Top comments (12)
I wouldn't get too obsessed over patterns. They can be handy to know once you can recognize the problems they solve. But in my experience it's harder to work the other way, starting with the patterns. The danger in starting with patterns is making abstractions which don't end up fitting your problem. Focus on solving the problem first. You'll start to develop an intuition on when the patterns apply.
You don't choose design patterns, they choose you!
Honestly, dp are just best practices, at beginning of your career you usually are worried about them, later on you use them without thinking this is a state, this is a decorator... They become tools inside your toolbox.
A few passages from the Gang of Four Design Patterns book stand out.
From the Preface:
From Chapter 1 (Introduction):
Knowing the appropriate design patterns for the context in which you are working is a good thing. But patterns are, in my opinion, first and foremost a communication tool. You can have a good design without knowingly using any patterns. However, understanding patterns and information about things like the intention, motivation, and participants and their responsibilities allow you to talk about and understand other people's designs, which can help you improve your designs.
At the end of the day, though, focus on good design principles, not trying to use patterns. As you read about other people's designs along with the problems they were trying to solve and the tradeoffs they made, you'll come across various "patterns".
Hi. I believe that it is more reliable to think about what not to do, rather than thinking in patterns itself. Your second question is a common example of "golden hammer" or "silver bullet" anti pattern. Don't assume that your favorite solution could resolve all the problems.
Maybe a pattern could fit in your proyect or maybe not, but you should not force them. Pherhaps you have a simple project with 2 or 3 classes, and forcing a "abstract factory" or "decorator" result in a overpowered architecture (and confusing, by the way). Sometimes keep it simple is the best.
Now, if you need to start a project with a complex architecture, with many clases and too much interconnection between objects, maybe you should think a bit more and check wich pattern could fit in some situation, but always using the "divide and conquer" strategy first. Always is simplier to resolve many easy problems than a very difficult one. Then, the patterns appear naturally.
Not knowing design patterns is not bad at all, but they could help you a lot. They gives you generic solutions for many common problems
I agree with this line of thinking. The design patterns also sort of find their way to you when you need them most. I personally am not well-versed on design patterns in general, mostly reliant on the pattens I've acquired along the way when I need them, either formally or through natural independent invention.
When I was Lead and had to design a project from scrath (OOP), I printed cheatsheets and glue them to a nearby wall.
When we reached the implementation phase we can quickly search if a problem we have can be solve by one or a mix of known design patterns.
I've actually been looking at doing this. Not just for design patterns but for JavaScript in general. I read a lot and there's only so much information I can take in. I often know there is a concept out there or need a slight prompt. I believe cheat sheets are a great way to jog your memory. I found them especially useful back when I was learning new languages.
I think in this case there is a distinction between the patterns used within modules and then there's the patterns used to organise my projects & modules. In the cheat sheet it terms these are structural vs creational which is a great initial distinction to make!
Your post has actually got me on the hunt for some other cheat sheets github.com/addyosmani/essential-js...
Yes there are many patterns and you only use them when starting a new project / system / module, impossible to remember them all.
Especially in JS where you can jog between multiple programming paradigms, our brain can be overloaded so cheatsheets are here to rescue us. From DRY/SOLID principles to JS module patterns it's good to make some wall posters from them.
Good point around the beginning of the project. I'm just starting out building a telegram bot which will use a lot of custom commands for authenticated users.
I've decided instead of doing my usual "write code - suffer pain - refactor" mantra I will plan out elements of the architecture.
As an example, since every message would be running through my application I expect a middleware pattern would be useful for logging, checking for authentication levels, spotting messages that contain commands and attaching a custom handler.
Once the message is picked up by the handler I could use a plugin based architecture as there are many commands that I would treat as custom hooks to be fired in response to the routed command.
Even having a rough implementation view at this level will help to structure my project. I can then begin delving into the creation patterns such as an InstantMessage class which creates a structure I can then utilise in my concrete classes which hold the detail of the commands.
Offtopic - I made some bots in the last 2 years and I came across this generator that does something simple and beautiful
Thanks for this sounds like it will give me a nice framework to review and steal with pride.
I think there are very different types patterns that you could use in various situations.
For starters there are dp that are nearly always a good idea such as facades or adapters.
Then there are patterns that fit a special model-structure as containers, fabrics etc, you'll recognize them when they fit your project.
Then there are patterns you just are aware of because you just used them for any recent project, maybe per accident, maybe someone told you to, maybe you read about them - if they were helpfully you'll try to reuse them, hopefully they're fitting again.
At last there are dozens of patterns you're not even aware of. While experimenting you could try to do stuff with them, but you usually don't try to pick one and make your project fit to it.