Hi, I am Michael, a Tech enthusiast and a Flutter Developer. I recently started reading a book by Gang of Four: Design Patterns: Elements of Reusable Objects. So, I decided to share and contribute my knowledge to the Flutter community. And this article is an excerpt and a summary of what I've learnt from the book.
This article gives an introduction to a Pattern, Design patterns, and 4 essential elements of a pattern.
Introduction
Designing object-oriented software is hard, and designing reusable object-oriented software is even harder. You must find pertinent objects, factor them into classes at the right granularity, define class interfaces and inheritance hierarchies, and establish key relationships among them. In designing reusable object-oriented software your design should be specific to the problem at hand but also general enough to address future problems and requirements. In doing this you would also want to avoid redesign, or at least minimize it.
What is a Design Pattern?
A design pattern names, abstracts, and identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design. The design pattern identifies the participating classes and instances, their roles and collaborations, and the distribution of responsibilities. Every design pattern focuses on a particular object-oriented design problem or issue. It describes when it applies, whether it can be applied in view of other design constraints, and the consequences and trade-offs of its use.
Design patterns make it easier for you to reuse successful designs and architecture. Design patterns also help you choose design alternatives that make a system reusable and to avoid alternatives that compromise reusability.
A pattern is a written document that describes a general solution to a design problem that recurs repeatedly in many projects.
In general, a pattern could be described as an Avatar with 4 bending elements
A pattern also has four essential elements..
** Element 1. Water **
The Pattern name
The pattern name is a handle we can use to describe a design problem, its solutions, and its consequences. It is essential for us to name a pattern because having to know a name for a pattern increases our design vocabulary. Which in turn lets us design at a higher level of abstraction. Having a vocabulary for patterns lets us talk about them with our colleagues, in our documentation, and even to ourselves. It makes it easier to think about designs and to communicate them and their trade-offs to others.
** Element 2. Earth **
The Problem
The problem with reference to the *Gang of Four * describes when to apply the pattern.
It explains the problem statement and its context. The problem might describe specific design problems such as how to represent algorithms as objects, It might describe class or object structures that are symptomatic of an inflexible design. Sometimes the problem will include a list of conditions that must be met before it makes sense to apply the pattern.
** Element 3. Fire **
The Solution
The solution describes the elements that make up the design, their relationships, responsibilities, and collaborations. The solution here doesn't describe a particular concrete design or implementation, because a pattern is like a model or a guide that can be applied in many different scenarios. Instead, the pattern provides an abstract description of a design problem and how a general arrangement of elements (classes and objects in our case) solves it.
** Element 4.. Air **
The Consequences
According to the 3rd law of motion. "Actions & reactions are equal and opposite".
The consequences of our actions here are the results and trade-offs of applying the pattern. Although consequences are often unvoiced when we describe design decisions, they are critical for evaluating design alternatives and for understanding the costs and benefits of applying the pattern. The consequences for software often concern space and time trade-offs. They may address language and implementation issues as well. Since reuse is often a factor in object-oriented design, the consequences of a pattern include its impact on a system's flexibility, extensibility, or portability. Listing these consequences explicitly helps you understand and evaluate them.
Conclusion
You must know that design patterns described in this article are not about designs such as linked lists and hash tables that can be encoded in classes and reused. Nor are they complex, domain-specific designs for an entire application or subsystem. The design pattern in this article is **descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context. ....
I hope this article encouraged you to learn more about patterns, design patterns, or programming in general.