After years of experience, I suddenly woke up recently and summarized my feelings, hoping to help you.
1. The demands mainly involve mentality and direction of thinking.
In the previous development process, we always wanted to investigate and sort out all the requirements in the early stage, and also hoped to confirm that they would not change. However, the reality often tells us how impractical this idea is and is impossible at all. Users cannot confirm all requirements, and we will continue to develop new requirements with our understanding of the business. As a result, when a development problem occurs, we always complain that the demand cannot be determined, and the demand always changes. With the increasing experience, I gradually find that it is better to understand the changes and change our development methods and processes than to complain about the changes, so as to better cope with the changes. In fact, isn't it one of our tasks to cope with changes?
2. Traditional methods (process-oriented) and object-oriented
Both traditional methods and object-oriented methods are one of our solutions to the problem. We should choose different methods to solve the problem according to the actual situation.
3. process the change method-help you transform from traditional methods to object-oriented methods
Many articles have explained how to analyze problems through object-oriented methods. Most of them are abrupt, it cannot help me switch from a traditional method to object-oriented (or, of course, I don't have enough understanding ). So I read a book and summarized the methods for handling changes to help myself. Now let me explain the method from an example.
Bill printing is a problem we often encounter in projects. First of all, I am an object-oriented newbie. Naturally, I am used to analyzing the problem in a traditional way. The bill printing analysis is as follows:
1. obtain printed information
2. Print the ticket
3. Report printed
(This is just an example, so please do not go too far into the example)
After the analysis, we can naturally write a print program based on the analysis, but we can find that step 2 is a very likely change. There are many reasons for his change, for example. 1. Printer changes; 2. Printing format changes; 3. Multiple printing methods must coexist. In both cases, we can still solve the problem in the traditional way (using the function to separate the printed bill part). What about the 1st cases? It will be a headache if you want to come.
This is something we can naturally think. We can define several print objects to deal with different situations, and we can also think of defining an abstract class by defining a certain object-oriented basis, then multiple print objects are implemented through inheritance.
To print the ticket object, we get:
However, we still find it uncomfortable to use the print ticket object. We need to use multiple selection statements in the main object to create different print objects. If we still need to modify the primary object for new requirements, this is obviously not good. So we want to create the printed ticket object independently, and use a new object to take charge of the work; the primary object only needs to tell the new object what type of printed ticket object it wants. So we have a new graph:
Here we have basically completed the process of printing the changes in the ticket part. The latest method improves the ability of this Part to respond to changes. With the possible changes in the system, we will gradually move into the object-oriented world.
About Changes: it is very difficult to directly discover future changes, but it is relatively easy to find the places that may change.
