Finally, now is the time that we start talking about design patterns! What are design patterns?
Design patterns were first introduced by GoF (Gang of Four), where they mentioned them as being solutions to given problems. If you would like to know more, GoF refers to the four authors of the book, Design Patterns: Elements of Reusable Object-Oriented Software. The book's authors are Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, with a foreword by Grady Booch. This book covers software engineering solutions to the commonly occurring problems in software design. There were 23 design patterns first identified, and the first implementation was done with respect to the Java program language. Design patterns are discoveries and not an invention in themselves.
The key features of design patterns are as follows:
They are language-neutral and can be implemented across multiple languages
They are dynamic, as new patterns get introduced every now and then
They are open for customization and hence useful for developers
Initially, when you hear about design patterns, you may feel the following:
It's a panacea to all the design problems that you've had so far
It's an extraordinary, specially clever way of solving a problem
Many experts in software development world agree to these solutions
There's something repeatable about the design, hence the word pattern
You too must have attempted to solve the problems that a design patterns intends to, but maybe your solution was incomplete, and the completeness that we're looking for is inherent or implicit in the design pattern. When we say completeness, it can refer to many factors such as the design, scalability, reuse, memory utilization, and others. Essentially, a design pattern is about learning from others' successes rather than your own failures!
Another interesting discussion that comes up on design patterns is—when do I use them? Is it in the analysis or design phase of Software Development Life Cycle (SDLC)?
Interestingly, design patterns are solutions to known issues. So they can be very much used in analysis or design, and as expected, in the development phase because of the direct relation in the application code.
The advantages of design patterns are as follows:
They are reusable across multiple projects
The architectural level of problems can be solved
They are time-tested and well-proven, which is the experience of developers and architects
They have reliability and dependence
Not every piece of code or design can be termed as a design pattern. For example, a programming construct or data structure that solves one problem can't be termed as a pattern. Let's understand terms in a very simplistic way below:
Snippet: This is code in some language for a certain purpose, for example, DB connectivity in Python can be a code snippet
Standard: This is a way to solve some kind of problems, and can be very generic and applicable to a situation at hand
Pattern: This is a time-tested, efficient, and scalable solution that will resolve the entire class of known issues
To use design patterns efficiently, application developers must be aware of the context where design patterns apply. We can classify the context into the following main categories:
Participants: They are classes that are used in design patterns. Classes play different roles to accomplish multiple goals in the pattern.
Non-functional requirements: Requirements such as memory optimization, usability, and performance fall under this category. These factors impact the complete software solution and are thus critical.
Trade-offs: Not all design patterns fit in application development as it is, and trade-offs are necessary. These are decisions that you take while using a design pattern in an application.
Results: Design patterns can have a negative impact on other parts of the code if the context is not appropriate. Developers should understand the consequences and use of design patterns.