 |
|---|
| The Cover of Article is Adapted From “Design Patterns Explained Simply By Alexander Shvets” Cover Page |
At the beginning, it is necessary to say that this text is adapted from several reference books on the subject of Design Patterns, which we will mention to them at the end of this article, and the author of this article had no influence on its scientific content. I strongly recommend reading the sources.
Object-Oriented software design is a difficult task and reusable design is even more difficult. If you don't know anything about Object-Oriented, reading this article won't help you much, and it can be said that the prerequisite for learning Design patterns is mastering Object-Oriented concepts.
If you have programmed, you have noticed that at the end of programming, you have been able to give a solution to the problem that was in front of you, and if you have gained this experience many times, you will notice that you have encountered with the same problem domain which you have faced before and you were able to find a solution for it. Now it may be a duplicate problem domain, but due to the different conditions and situation types, you have not been able to use the same previous solution for this repeated problem and you have had to find a new solution for it. In other words, it can be said that your design is not flexible and reusable, and it has caused you to provide different solutions for repetitive problems, and this is not a good thing. Our design must be reusable, and this is not the only feature of a good design, in fact, other factors such as elegant, flexible, and efficiency are among the other criteria of a good design.
Now, a question arises, how to deal with a new problem domain, taking into account the mentioned criteria, to make a design so that when we face the same problem again in the next work, we can get the desired solution with minimal changes in our previous solution?
In response, it should be said that this is not an easy task at all and requires a lot of successful experience. It means that it becomes possible with the passage of time. You should record the experiences and results obtained after each design and use previous experiences repeatedly and improve your design skill, which is called Sprint-Retrospective, and finally become an expert object-oriented designer. You definitely don't have that much time to spend on gaining experience so that you can do a design with the mentioned criteria. This is where the issue of Design Pattern comes into play
There are a series of recurring problems in our world that we encounter many times. Experienced designers have found a solution for those problems once and forever. Each pattern represents a problem with its own solution, in other words, a design pattern must be the best practice for the relevant problem (that is, there is no better solution for that problem domain) and the duty of a designer is to do pattern matching, that is, to figure out which design pattern corresponds to the problem ahead.
- It should be such that we no longer need to think about the problem and our only job is pattern matching. This property is called Smart.
- It should not be dependent on a specific type of system or programming language, it should be specific to a general problem domain, which is called Generic.
- It must be proven that the proposed solution will definitely solve our problem and does not need to be proved again, which is called well-proven.
- It should be simple.
- It must be Reusable, which we explained earlier what it means.
- All Design Patterns solutions are based on the Object-Oriented paradigm.
We recommend that you read the text again from the beginning and then continue.
- Each Design Pattern has a Name consisting of one or two words, from which one can understand the definition of Problem, Solution, and result (that is, a name related to what it does, not the name of its creator).
- The second part is the Problem, which should explain the problem and its context, for example, how we can represent an algorithm in the form of an object. Sometimes the problem includes a list of conditions that must be checked whether they exist or not, and then according to the result, we decide whether this design pattern is useful or not.
- The third part is ــSolutionــ, which introduces elements whose task is to make up the relationships, responsibilities, and collaborations of a design. Solutions do not have a specific implementation because they are like a template that is used in different situations and mostly include UML diagrams.
- The fourth section is Consequences & Trade-off, which represents the result of a pattern. Basically, its role is to evaluate a design and determine the costs and benefits of using a design pattern.
Two items are used to classify design patterns. The first is Purpose, which reflects that a Design Pattern is placed in different categories in terms of what it does, all of which fall into three categories: ــCreational, Structural, and Behavioral, we will describe the characteristics of each category. The next item is Scope, which specifies whether a Pattern is used in Class format or Object format. Those that are placed in Class Scope work with the relationship between classes and subclasses, like the Inheritance concept, they are also static and fixed at compile-time, but those that are in Object Scope work with the relationship between objects. They can change in Run-time and are dynamic
 |
|---|
Creational Patterns are used when the Instantiation Process is particularly important for us, and in Design, we use these types of Design Patterns depending on different conditions and situations. This type of pattern gives you a lot of flexibility in matters such as: what was created, who created it, how it was created, and when it was created.
Structural Patterns focus on how classes and objects are composed to build larger structures. Those Structural Patterns that are in Class Scope use Inheritance to compose Interfaces. These types of Design Patterns are particularly useful for developing independent Class Libraries that can work together.
Behavioral patterns are involved with algorithms and responsibilities between objects. This type of pattern not only describes the class and object but also defines the communication between them. This type of pattern is suitable when our control flow is complex and following it is a difficult task in Run-time. These types of patterns take our focus away from control flow and allow us to focus only on how objects are interconnected.
Next sessions, we will start introducing Design Patterns and implement each one as an example in Java, C#, and C++ languages.
- Design Patterns Elements of Reusable Object-Oriented Software -Gmma and Helm and Johnson and Vlissides -Addison Wesley
- UML 2 Toolkit -Eriksson and Penker and Lyons and Fado –Wiley
- Java Design Patterns -Rohit Joshi -Exelixis Media