A design pattern is a general, reusable solution for commonly occurring problems. The basic idea is that you can solve similar kinds of problems with similar kinds of solutions. In addition, these solutions have been tested over a long period of time.
Patterns generally provide a template of how to solve a problem and can be used in many different situations. At the same time, they help you to achieve the best possible design much faster.
Patterns are descriptions of how to create objects and classes and then customize them to solve a general design problem in a particular context
In the early days of software development, engineers faced a common problem—there was no standard to instruct them how to design their applications. Each team followed their own style, and when a new member (experienced or unexperienced) joined an existing team, understanding the architecture was a gigantic task. Senior or experienced members of the team would need to explain the advantages of the existing architecture and why alternative designs were not considered. The experienced developer also would know how to reduce future efforts by simply reusing the concepts already in place. Design patterns address this kind of issue and provide a common platform for all developers. You can think of them as the recorded experience of experts in the field. Patterns were intended to be applied in object-oriented designs with the intention of reuse.
Gang of Four
In 1994, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides published the book Design Patterns: Elements of Reusable Object-Oriented Software (AddisonWesley, 1994). In this book, they introduced the concept of design patterns in software development. These authors became known as the Gang of Four.
The GoF discussed 23 design patterns. Each of these patterns focuses on a particular object-oriented design. Each pattern can also describe the consequences and trade-offs of use. The GoF categorized these 23 patterns based on their purposes, as shown here:
Creational patterns
These patterns abstract the instantiation process. You make the systems independent from how their objects are composed, created, and represented. The following five patterns are this category:
Singleton pattern
Prototype pattern
Factory Method pattern
Builder pattern
Abstract Factory pattern
Structural patterns
This category focuses on how classes and objects can be composed to form relatively large structures. They generally use inheritance to compose interfaces or implementations. The following seven patterns fall into this category:
Proxy pattern
Flyweight pattern
Composite pattern
Bridge pattern
Facade pattern
Decorator pattern
Adapter pattern
Behavioral patterns
Here the concentration is on algorithms and the assignment of responsibilities among objects. You also need to focus on the communication between them and how the objects are interconnected. The following 11 patterns fall into this category:
Observer pattern
Strategy pattern
Template Method pattern
Command pattern
Iterator pattern
Memento pattern
State pattern
Mediator pattern
Chain of Responsibility pattern
Visitor pattern
Interpreter pattern
Anti patterns
The discussion of design patterns is not complete without talking about anti-patterns.
With design patterns, you reuse the experience of others who came before you. But when you start blindly using those concepts too much without thinking critically about what you’re doing, you can create problems in your programs. As a result, over a period of time, you may find that your return on investment decreases while your maintenance costs increase.
If you apply a design pattern in the wrong context, it can cause more trouble than the problem it solves, and eventually it will turn into an anti-pattern. So, before you start, understanding the nature and context of the problem you’re solving is important.
DesignPatterns
design patterns
02.11.2018
Acasa