Study Notes: What is the design model?

Mode

Patterns comes from the timless way of building of Christopher Alexander.
"Is Quality Objective ?" Starting from this question, Alexander began to think about the difference between a good design and a bad design? Or, what does a good design contain? What does a bad design contain? After much observation and research, Alexander found that good construts had things in common with each other, despite its wide variety of design structures ). Alex understands that the structure and solution of the problem cannot be separated, so he focused his research on the commonalities of the structures that can solve similar problems. These high-quality designs are the "pattern ".
So Alex defined the mode as "a solution to a problem in a context ), each mode describes repeated problems in the environment and the core of the solution. With the mode, we can continue without repetitive work.
In alex, the pattern has the following four elements:
1. Name (name of the pattern );
2. Purpose of the pattern, the problem it solves );
3. Implementation (how to accomplish );
4. Constraints and factors to consider (constraints and forces we have to consider in order to accomplish it );

Software Model

In the 1990s s, some smart developers accidentally came into contact with Alexander's book about models, is there a pattern in software development? Can repeated problems be solved in the same way? Once the model mode is established, can this mode be applied in the new design? The answer is yes.
As a result, we have the famous "the Gang of Four" and the famous design model. According to the definition of this book, software design patterns have the following elements:
1. Name, the identifier of the Mode
2. Purpose (intent): The purpose of the Mode
3. problems to be solved by the mode
4. Solution
5. Participants and collaborators, entities included in the pattern
6. consquence. Apply this mode to the impact of present forces.
7. Implementation (implemention): the implementation method of the mode is just a description of the mode, not the mode itself.
8. gof reference: get more information about this mode from the help.

At the same time, the Gang of Four provides several general suggestions:
1. design to interfaces)
2. Try to use combination (favor composition over inheritance)
3. Find the variables to encapsulate (find what varies and encapsulate it)

Value of the Model

The value of the model is embodied in the following three aspects:
1. Reuse of solutions-use existing development models to learn from others' experiences and prepare avoid gotchas to reduce development costs and risks;
2. Establish general terms-in the project analysis and design phase, the model provides a conventional vocabulary and perspective, which is conducive to internal communication within the team
3. Release the perspective-both the question and the design and design patterns provide a high-level perspective, so developers do not have to concentrate on the details from the very beginning.

Example

The idea of building a drawer is as follows:
Carpenter A: How do we make this drawer?
Carpenter B ......

Don't laugh. In many cases, the programmer's thinking is similar to Carpenter B. Here, I use a while loop to achieve a certain purpose ...... Then I start to use if to determine the condition ...... Here we will use swich for processing ......
Carpenter A is concerned about whether to create a drawer or a drawer. The A-type drawer is easy to implement, with a low load and looks very general. The B-type drawer is relatively complicated, but it can withstand high temperature and humidity without bonding. If it is well done, it is very beautiful.
Therefore, the focus of carpenter A is whether to create a-type drawer or B-type drawer?
Once this is determined, the rest is implemented in an existing way. Anyone will see that carpenter a's thinking (that is, model thinking) is far better than carpenter B's.
--------------------------------------------

Christopher Alexander said: "Each pattern describes a recurring problem around us and the core of the solution to the problem. In this way, you can use this solution again and again without repetitive work ".
Though Alexander refers to city and architectural patterns, his ideas also apply to object-oriented design patterns, but in Object-Oriented solutions, we replaced walls and doors and windows with objects and interfaces. The core of the two models is to provide solutions to related problems.

The design pattern in the software Describes a general solution to a certain type of common problems in the software design process.

The object-oriented design mode describes the common organizational relationships between classes and communication objects in specific scenarios during the object-oriented design process.

Design Pattern and object-oriented
1. The object-oriented design model solves the "Organizational Relationship between classes and communication objects, including their roles, responsibilities, and collaboration methods ".
2. The object-oriented design mode is "Good object-oriented design" because it can meet the requirement of "responding to changes and improving reuse ".
3. Object-oriented Design Patterns Describe software design, so they are independent of programming languages. However, the ultimate implementation of object-oriented design patterns still needs to be expressed in object-oriented programming languages.
4. Unlike algorithm techniques, the object-oriented design pattern can be directly copied and used. It is an empirical understanding based on a pure and in-depth understanding of "Object-Oriented. The premise of understanding the object-oriented design model is to first master the "Object-Oriented "!

Intuitive understanding of object-oriented programming languages
Various object-oriented programming languages are different from each other, but we can see their support for the three major object-oriented mechanisms, namely, "encapsulation, inheritance, and polymorphism"
● Encapsulation: Hiding internal implementations
● Inheritance: Use existing code
● Polymorphism: rewrite object behavior

However, oopl is not all object-oriented.
The object-oriented programming language (oopl) is not all of the object-oriented, or even a simple object-oriented.
Oopl did not answer the fundamental question of object-oriented-why should we use object-oriented? How should we use three mechanisms to achieve "Good Object-Oriented "? What kind of object-oriented principles should we follow?

What is an object?
-In terms of concept: an object is an abstraction with certain responsibilities.
-In terms of specifications: an object is a series of public interfaces that can be used by other objects.
-In terms of language implementation, the object encapsulates code and data.

From design principles to design patterns
· Programming for interfaces (abstract Part) instead of implementation (specific part)
-The customer does not need to know the specific type of the object in use, but only needs to know that the object has the interface that the customer expects.
· Prioritize the use of object combinations, rather than class inheritance
-Class inheritance is usually "white box reuse", and the object combination is usually "black box reuse ". Inheritance destroys encapsulation in a program, and the Child class parent class has a high Coupling Degree. The object combination only requires that the combined object has a well-defined interface, and the coupling degree is low.
· Encapsulation changes
-Use encapsulation to create the demarcation layer between objects, so that the designer can modify the interface on one side of the demarcation layer without adversely affecting the other side, so as to implement loose coupling between layers.
· Use the refactoring Mode
-The application of the design pattern should not be preemptible. the first use of the design pattern is the biggest misuse of the design pattern. There is no one-step design model. The "refactoring to patterns" advocated by agile software development practices is widely recognized as the best way to use the design pattern.

Several more specific design principles
· Single responsibility principle (SRP): A class should have only one reason for its change.
· Open and closed principle (OCP): class module, which is open to extensions and closed to changes.
· Liskov replacement principle (LSP): subclasses must be able to replace their base classes.
· Dependency inversion principle (DIP): High-Level modules should not depend on low-level modules, both of which should depend on abstraction.
Abstraction should not depend on implementation details, but on abstraction.
· Interface isolation principle (ISP): customer programs should not be forced to rely on methods they do not need.