Agile Software Development-open-closed principle (OCP)

Origin:

What kind of design can we face the changes in requirements, but it can be relatively stable, so that the system can continue to launch new versions after the first version? The well-known development-closed principle (the open-closed princle) proposed by Bertrand Meyer in 1988 provides us with guidance.

The modules designed according to the open-closed principle have two main features:

1. "Open for extension)

This means that the module behavior can be expanded. When the application needs to change, we can expand the module so that it can satisfy those changes. That is to say, we can change the function of the module.

2. "Closed for changes" (closed for modification)

You do not need to modify the source code or binary code of the module when extending the module behavior. The binary executable version of the module, no need to change whether it is a linked library or DLL.

These two features seem to be in conflict. How can we change the module's behavior without modifying the module's source code? How can I change the function of a module without having to modify it?

The key is abstraction.

In C ++, you can create a fixed abstract body that can describe any possible behavior. This abstract body is the abstract base class, and a group of people can act as a possible derived class.

This base class does not need to be modified. The member methods (interfaces) in the class are declared as pure virtual functions. The specific implementation can be implemented, changed, and extended in the derived class.

Using OCP, you can clearly split a common functional part from the implementation details.

In practical application, the designer must determine which changes should be closed for the modules designed by the designer. He must guess the most likely behavior to change, and then construct an abstraction to isolate these changes.

This requires the designer to have the ability to predict from experience, and the designer must be familiar with the application field to determine the possibility of various changes. Then, he can design a reasonable OCP.

In fact, it is difficult to predict all possible changes in the first design,

So how can we isolate changes?

1. Be fooled only once

There is a saying: "You should be ashamed to fool me once. I should be ashamed to fool me again ." This is also an effective attitude towards software design, and we will allow ourselves to be fooled once. This means that when we first write the code, the assumption will not change. However, when a change occurs, we create an abstraction to isolate similar changes. In short, we are willing to be hit by the first bullet, and then we will ensure that we will not be hit by other bullets from the same gun.

2. stimulate changes

If we decide to accept the first bullet, the sooner the bullet arrives, the better. The sooner we find the problem and solve the problem. We hope that the possible changes will not be known in the development process. The longer it takes to identify possible changes, the more difficult it is to create a correct abstraction. Early detection and early resolution

Therefore, we need to stimulate changes:

* Write a test

* Use a short iteration cycle for development

* Release software as early as possible and frequently. Present the software to customers and users as frequently as possible to receive feedback from them.

Summary:

In many aspects, OCP is the core of object-oriented design. Following this principle can bring about the great benefits that object-oriented technology claims (flexibility, reusability, and maintainability ). However, it does not mean that we follow this principle as long as we use an object-oriented speech. It is not a good concern to abstract every part of the application. The correct approach is that developers should only abstract those parts that present frequent changes in the program. Rejecting immature abstractions is just as important as abstraction itself.

Agile Software Development-open-closed principle (OCP)