Understanding of design patterns

Speaking of the design patterns, we have to mention gof23 design patterns. These design patterns are described in a historical classic book: design patterns: the basis for reusable object-oriented software, the four authors of this book are also known as Gang of Four (gof ). Because this book is very influential, the design patterns we usually call are implicitly represented as "Object-Oriented Design Patterns ", however, this does not mean that the "Design Pattern" is equivalent to the "Object-Oriented Design Pattern ".

Many people think that the design pattern is a rule or a solution. They think that the design quality can be improved by using the design pattern. I think this is the case before I get started with the design patterns. However, this idea is incorrect. The design model is not a rule that we must follow, nor a solution, but a choice that is relevant to a certain context and comprehensively considered, it is the choice of a solution that balances the advantages and disadvantages of each aspect in a specific scenario. This choice is the result of balancing these advantages and disadvantages. We will also pay the appropriate price when obtaining the benefits, therefore, the design model can not be used in any situation. More intuitively, after balancing the advantages and disadvantages, it is useful only when the advantages and disadvantages are greater than the disadvantages, otherwise, it will only be counterproductive and bring us troubles in our design. Whether or not the design model is used depends on whether the project meets the model and whether the cost is within the acceptable scope of defense, sometimes we can solve some simple problems well without using the design pattern, so we should be careful when using the design pattern to avoid unnecessary troubles.

Can the use of design patterns increase our development speed? This problem should be considered in two aspects. In the short term, using the design pattern may introduce more objects and more complex assembly relationships, so that the program has more dynamic states and the local structure becomes more complex, difficult to understand and test, it seems that things are getting worse, and the development cycle is definitely getting longer, but this is just a superficial phenomenon. From the perspective of the entire development cycle of the project, rational use of the design pattern will make the program structure more robust and better maintainability. The requirements of current software development customers cannot be kept unchanged. A poorly structured program may have a fast development book in the early stage, but once the customer's requirements change, it takes more time and effort for maintenance. So in the long run or in the whole life cycle of the software, the time and energy spent in using the design pattern is more convenient for later maintenance and is worth it. Because the design pattern we are talking about now refers to the object-oriented design pattern, the learning design pattern is based on understanding the object-oriented. Speaking of object-oriented, we usually think of object-oriented languages, such as C ++, C #, and Java. There are differences between these languages, but they all support the three major object-oriented mechanisms: "encapsulation, inheritance, polymorphism ". However, object-oriented languages are not all object-oriented. If you are familiar with object-oriented languages, you can understand them very well. I am just getting started, and I am still working hard. Of course I can't talk about how deeply I understand Object-oriented thinking, but I think it is very important to understand this idea, do not mistakenly assume that you are proficient in object-oriented languages.