In software practice, when focusing on a specific scene design, many people in us, very few time, or willing to take deeper things in their thinking. And when the design is finished, if we want to relax because of the troubles of the birthplace, then wait back to the head, then try to make some summary, but find that you have become ambiguous about those specific practices. . These details are likely to be a source of very valuable ideas. This is like a person hurriedly got a road, and then stopped for a while, waiting for him to stand up again, but he had forgotten the way. Unfortunately, the author belongs to such a person. This article tries to do some memories of "past" and hopes to thus throw everyone's thinking.
What did we see?
When we stand in the high-level building, maybe we can't see each of these high buildings, the formation of doors and windows, the profiles used ..., but we have seen their overall structure and trend. In an OO system, it is true that when we ignore the specific details, what do we see when we look at the buildings in these Oo worlds? I think that most of us is a series of objects, as well as the relationship between these objects.
After knowing the overall structure and trends present in front of us, follow-up problems.
What are we doing?
From the above view, our design process is equivalent to: Out of the object itself, clarify its responsibility; arrange the relationship between objects to make it a whole. On this issue, although there are many methods, no exception is that all methods are doing this same thing.
After understanding the object and behavioral itself of our behavior, the problem is produced.
What is our goal?
There are also several related questions: how to evaluate our behavior (ie evaluation standard issues)? What are we doing? What extent? If we use the target as an evaluation criteria, then these problems can be independent of the same. As for the evaluation criteria, we can make a harsh, nearly perfect goal, and there are many such candidates available. However, just as Kent Beck said:
"Program Have TWO Kinds of Value: What the can do for you today and what the can do for you tomorrow."
Many standards, and finally can be divided into two categories: the correct implementation is achieved correctly; it is guaranteed that follow-up development smoothly. When an OO design (that is, the result of our behavior), no existing needs, do not doubt, it is naturally a failure, it is a bad design. And after we solved the "warm problem", we have the opportunity to put your eyes longer, we have begun to consider how to make the system structure more reasonable and more delicate; how to make it easy to transplant, easy to reuse; The demand for changes, how to make greater flexibility; and begin to consider the problem of efficiency and cost. Under the ideal situation, our description is like this, that is, we first consider the first class evaluation criteria, then consider the second class, both occasionally cross. But the fact is often, we will easily mix these both, and the more excellent Programmer, the more likely, the problem is, the better, a good Programmer, not necessarily a good Designer).
The object of behavior, behavior itself, the goal of behavior has the goal of behavior, and it seems that all the problems with understanding are clear, this is the last one, the most attractive, most worth exploring the problem. How should we do it?
If these discussions and philosophy are more than a class, then the foregoing is about to belong to the category of ontology, and it should belong to the category of methodology. There are many ways to choose, compare new: Design Pattern, Refactoring. There are also some traditional object-oriented design methods, of course, Quick and Dirty. For different scenarios, the target selection (both evaluating the standard selection) may be focused, which has the basis for choosing different methods. A way is not the most suitable at any time. It depends on what kinds in many evaluation criteria you prefer. Sometimes these criteria are often contradictory, so you have to make a compromise in the middle of them, seek balance points. The biggest pair of contradictions exists between the two types of evaluation criteria, another pair of contradictions in some occasions, is "structural and efficiency" (such as an embedded system application).
summary
After I met the four basic problems mentioned above, we saw a frame existing in the OO world, a self-enclosed, logically complete conceptual framework. Each problem (ascending) is not repeated each other, and it has successively before and after. In the world of OO, each "object" (including things, concepts, methods, etc.) can be merged into one of the above, and there are logical associations between them. Every day, we are doing things we should do in such a frame.
Personal point of view, only for reference.
