Design patterns are an important consideration when designing or developing any software systems or solutions. There is so much buzz around patterns. At the same time, we often get confused about their use. Basically we get questions like the following:
- What design patterns are
- Why to use them
- When to use them
- How many patterns we have
In the first part of the series around design patterns, we will try to discuss and answer these questions.
What design patterns are
Design patterns are basically proven solutions to common design problems. They can also be defined as recommended practices to solve any recurring problem in application design.
Please be clear that, design patterns are not ready-to-use code that can be used directly, instead they present approaches or recommendations to solve daily design challenges.
Why to use them
The reason for usign them is simple. Why re-invent the wheel, when we have workable, tested and well documented solutions for a set of common recurring problems?
We should use design patterns (when required) to design and develop reusable and scalable components that in turn helps the development team to finish the development activities in due time while attaining high quality.
Designing an application in a standard or tested fashion also helps other developers and code reviewers to understand the written code easily.
When to use them
This is a very pertinent issue and we should be well aware of their usefulness. Using design patterns without evaluating them properly can make the design unnecessarily complex.
There could be instances when you might not need them at all and you can simply live with basic OOP design principles.
Whether to use them or not depends on the scenario at hand. Each pattern talks about specific design problems and the standard solution for that. So before using them, spend a fair amount of time in analyzing your design issues and try to match it with the once-discussed in patterns.
I would like to emphasize the point that the key to find the right pattern is to understand and identify the scenario that any pattern is trying to address.
Once you find the right pattern for your specific problem or scenario, you can apply it to your software design.
The many patterns
There is no specific number of patterns, since they kind of evolve over time and the software industry has used and tested them. Having said that, there are folks like the “Gang of Four” that have well-documented and popularized them in the software development community. I also find SOLID design principles to be worth refer to.
To summarize the discussion, I would like to say to start your design with a few basic design principles, like clean coding, loose coupling and modular design and so on and continue to evaluate design challenges with known and existing issues discussed in design patterns. After evaluation, if you find any matching pattern then go ahead and use it else stick to whatever you have designed.
One last thing. Please don’t force your application to use design patterns. Instead use them only if it makes sense.
I hope you have liked the article. Please share your comments.