Agile Software Development-open and closed principle OCP

First, let's analyze the background. What are the most unstable factors in the software development process? -- The answer is demand! Requirements may change all the time during software development. Then, how to flexibly cope with changes is the most important and difficult issue in software structure design. A good design brings great flexibility, and a bad design is filled with a rigid smell. This leads to the topic of this article: [closed development principle ].

Next, we will briefly introduce what is the [open and closed principle ]. [Closed development principle] has two features: open for expansion and closed for modification. Open extension means that the module behavior is scalable. For modification and blocking, that is to say, when the module behavior is extended, there is noCodeOr modify the binary code (. Jar. Of course, this is too absolute. Sometimes you have to modify the existing code to complete some tasks. However, our goal is to follow the principles as much as possible.

So how can we implement extension development and disable modification? The key lies in abstraction! So what is abstraction?

My personal understanding is that abstraction is a conceptual understanding of the nature of things. Behavior analysis should be the main line in Object-Oriented Analysis. For example, from Beijing to Shanghai, we can fly, take a train, take a car, or ride a bicycle. How can we analyze this problem? What is the abstraction of this question? Maybe we can think like this: airplanes, trains, cars, and bicycles are essentially transportation tools. Therefore, the analysis result is as follows: transportation tools are abstracted as the parent class, and airplanes, trains, cars, and bicycles are all special implementations. The parent class defines an abstract method, A person can be transported from one place to another, and each sub-class can redefine the delivery method. This design is understandable! But pay attention to it! If someone is in a good mood one day and wants to go from Beijing to Shanghai. What is his vehicle? Road 11! If we calculate walking as a means of transportation, it would be too impractical. Therefore, from the perspective of object-oriented analysis, we should not analyze the physical association of things, but from the management area of things. For this problem, no matter how a person arrives from Beijing to Shanghai, the mobile strategy is different.

Below, we will give the corresponding sample code to illustrate the above problem.

Class traveller {
Private car = new car ();
Public void travel (address srcaddress, address destaddress ){
Car. Move (srcaddress, destaddress );
}
}

This is the first traveler to use car directly. What should I do if I want to replace it with airplane? Modify the code and use new airplane () instead of car. The object-oriented practice principle points out that interface-oriented programming is not oriented. When the Code depends on the specific implementation, it lacks flexibility. In the face of new extensions (that is, new implementations), you must modify the existing code.

Next, we will provide the Code with flexible design:

Class traveller {
Private travelstrategy _ strategy;
Public void travel (address srcaddress, address destaddress ){
_ Strategy. Move (srcaddress, destaddress );
}
Public void settravelstrategy (travelstrategy Strategy ){
_ Strategy = strategy;
}
}

Public interface travelstrategy {
Void move (address srcaddress, address destaddress );
}

Public class carstrategy implements travelstrategy {
Public void move (address srcaddress, address destaddress ){
...
}
}

Public class airplanestrategy implements travelstrategy {
Public void move (address srcaddress, address destaddress ){
...
}
}

Public class workstrategy implements travelstrategy {
Public void move (address srcaddress, address destaddress ){
...
}
}

With this design, you can flexibly cope with the design. For example, you need another method from Beijing to Shanghai-crawling. Haha, maybe this kind of behavior is incredible, but it can also achieve the goal. How can we expand it? You only need to extend a new travelstrategy implementation. In this way, the traveller class does not need to modify any code! You can call the setter method to change the mobile policy. There is another question: how to determine which policy to instantiate? The factory can be referenced here, which is responsible for Object Instantiation. You can put the desired policy in the file so that you do not need to modify it when changing the policy.Source code. However, when adding a policy, you still need to modify the factory. No way. In reality, there is no situation that fully complies with the principles. We can only try our best to abide by them!

Now let's take a look at the relationships between classes in the above Code. The traveller class, the travelstrategy interface, and its implementation class are the customer code of the travelstrategy interface. Which of the following is closer to travelstrategy and travelstrategy? The answer is the former. This is another agile principle [dependency inversion principle ]. High-level code should not depend on low-level code, and low-level code should depend on high-level code. Here, to put it bluntly, a traveler wants to go from Beijing to Shanghai, and the tour group has already arranged a way for him to go. He does not care about how to get there, you only need to know that there is a way to get there. The relationship between the traveler and the method of arriving is very close, and the specific way to arriving is a low level problem.

The above problems and implementation are a common method to achieve the [open and closed principle]-The Policy mode. There is also a common implementation method: Template Method. In fact, the essence of these two methods is the combination of object-oriented methods.

And inheritance.

We have learned how to encapsulate changes. How can we encapsulate changes? Mastering this skill is a good thing, but abuse leads to problems ~! Because OCP compliance is expensive, it takes time and effort to create a correct abstraction, and those abstractions also increase the complexity of software design. Generally, we adopt this method: only fooled once. That is to say, the initial implementation does not encapsulate anything. When real changes come, code refactoring and encapsulation changes will prevent similar problems from happening again.

OCP is the core of object-oriented design. Developers should onlyProgramAbstract The frequently changed parts. Rejecting immature abstraction is as important as abstraction itself.

Finally, let's briefly introduce the common methods of object-oriented analysis:

finding the commonalities of all things or actions in the problem domain
creating abstraction from commonalities
creating derivation from commonalities
View relations between commonalities