[Recommended] OO design principles

1. Why are we too involved in details? What is the nature of the problem?
Early attention to details during design is almost the weakness of most programmers, and it is also my own stubborn illness. Just as I was about to create an automatic update system shortly after my initial work, the development team's boss decided to use the FTP protocol at the design meeting. Do you know what I think in my head? -- "Indy components do not seem to support Chinese "......

Early attention to details may be due to two reasons: 1. with rich experience, I would like to draw a line from each other and outline all kinds of technologies. 2. I have no experience. I only know some technical details and it is difficult to jump out of my mindset. I know that I am the latter, and I used to be the present.

People are inert, and people tend to be proficient in themselves. Therefore, when designing a large framework, When I lack the ability to grasp it, I prefer to think about the details. This is a lazy process. There is no doubt about all technical details or problems (we are not doing scientific research), or you can easily get answers if you have questions, whether it is development documentation or in the community. The detailed solution is always obvious, but it is not necessarily the best start point.

Sometimes I really want to design it. I want to avoid getting stuck in "details", but I accidentally pulled in the details. Why? Profiling myself, I know this is because my thinking is tiled and there is no hierarchy. All the problems are stirred up together. When designing, it is inevitable to drag the water and the mud.

There is no layer of thinking. This is the essence of the problem. I need to design well, and the defects in the way of thinking become my destiny. What should I do? To be honest, I have been on a detour and I don't know if this road is right.
"A kind person is confused in his pursuit, but will eventually realize that there is a proper path." ----- Fushi de

 

2.. 2.Life-saving straw -- Martin Fowler's three-layer perspective Theory

Martin Fowler mentioned the three-layer perspective (perspective) in his book UML Distilled: conceptual perspective, normative perspective, and implementation perspective.

We can use three perspectives to view software development:

Concept: Presents various concepts in the field of study. When a conceptual model is obtained, we should try to minimize morality or ignore its implementation. The question to answer from this perspective is: what is software responsible? Is a strategic conclusion

Protocol perspective: We are considering software, but we are concerned with software interfaces rather than implementations. The question to be answered from the perspective of the Protocol is: how to use the software? This layer focuses on communication between various parts of the software.

Implementation: In this case, we will consider the Code itself, but in many aspects, we may be better at using the Protocol perspective. Software communication at the protocol layer is executed at the implementation layer.

The perspective helps us divide and isolate problems

From the above description, we can see that the problems involved in the design of "Software Development" have been divided into three different layers. At each layer, we must have specific ideas. When the top layer does not think about maturity, we will not proceed to the next layer. According to this principle, details are isolated from the walls of thinking.
The following question is, in the design process, what is the role of the three perspectives for problem hierarchy division?

 

3.3.Three-layer perspective -- let's look back at OO design principles
ConceptWe have obtained various concepts in the field. What are the objects responsible? This is a high-level strategy, which is usually highly abstract and a strategic conclusion. The key point is that it is stable. As long as the concept remains unchanged, the requestor is isolated from the changes in details. The handling of detailed problems should be postponed as much as possible. Focus on what the object is to do, instead of how it is to do it. Hiding these details helps us avoid premature details. What to do with an object is to define its responsibility. The best way to understand an object is to regard it as a responsibility.

Protocol perspective,An object is a group of methods that can be called by other objects or objects themselves (that is, behavior, how to use software ?); Objects are responsible. I only need to pay attention to the public interfaces of objects-this is a channel for me to require objects to complete some work. As long as the object interface tells us that it can fulfill a certain responsibility, it does not focus on how the object runs. Focusing on motivation rather than implementation is the basic OO design principle. Hiding implementation behind interfaces actually decouples object implementation from their objects.

Implementation perspectiveObjects are code and data, and computing interactions between them (how can the software fulfill its responsibilities ?); Here we will discuss the implementation details.

To sum up, we can refer to the following objects from Martin Fowler's three perspectives:

At the conceptual level, objects are a group of responsibilities.

At the protocol level, an object is a group of methods that can be called by other objects or objects.

At the implementation level, objects are code and data, and their computing Interaction

Here we need to rethink the basic OO principles:

From the concept layer to the protocol layer, our thinking results are abstract. They are abstract concepts and actions. At the concept layer, we clarify the responsibility of objects, at the protocol layer, we can see how objects with different responsibilities collaborate. Collaboration is a contract between objects. How are the responsibilities of objects divided? The object should be responsible for itself, and the object's responsibility should be as single as possible. This is the SRP principle. In the protocol layer, we define the interaction contract between objects, that is, interfaces. We have done this by focusing on interfaces rather than implementing them.

The concept layer is the most stable, and the implementation level is the most unstable. Therefore, higher-level modules should not depend on lower-level modules. Both of them should depend on abstraction. Details should depend on abstraction. This is the DIP principle. This principle implies that objects are only coupled at the conceptual level and cannot be coupled at the implementation level!

All interactions we define use the base class. What if a subclass cannot completely replace the base class during implementation? Is there a problem with all the interactive contracts? A subclass derived from a base class should support all actions of the base class. The base class must be replaced by the subclass. This is the LSP principle.

We can see that the responsibility and interaction of objects are defined as early as possible. In this process, we did not consider the specific object creation period and map it to our design process, the application of the Creation design pattern is often in the later stages of the design.

 

4. Conclusion:

·《OOSummary of design principlesI raised the following question:

How can we better use these principles?How to observe these principles in practice, using three perspectives to think about the problem is one of the answers;

· When designing, focus on high-level relationships first;

· Implementing the concept specification in the Process of Object design and development can improve our design capability and avoid getting into details too early.