Coding best Practices-open closure principle

Definition of open closure principle

There are two different definitions of the principle of openness and closure, namely the most primitive definition of the the 1980s and a more modern definition of the latter, which is elaborated in more detail in the former.

Definition of Meyer

Software entities should allow extensions, but prohibit modification

--"Object oriented Software construction"

Martin's definition

"is open for extensions. "This means that the behavior of the module can be extended. When the requirements of an application change, we can extend its modules to a new behavior that satisfies those requirements changes. In other words, we can change the function of the module.

"is closed for modification. "When you extend the behavior of a module, you do not have to change the module's source code or the binaries. The binary executable version of the module, whether it is a linked library, DLL, or java. jar file, does not need to be changed.

--"Agile software Development: principles, patterns and practices"

For the modification is closed

It is important to note that there are two exceptions to "closed for modification":

1. changes made to fix defects

2. client's inability to perceive changes

Bug fixes

Defects are common in software and are not completely eliminated. When defects occur, we need to fix the existing code. Software repair is clearly inclined to pragmatism rather than adherence to the principle of open closure.

Client-side Awareness

If a class change causes another class to change, then these two classes are tightly coupled. Conversely, if the modification of a class is always independent and does not cause changes to other classes, then these classes are loosely coupled. We have to remember that loose coupling is better than tight coupling in any case . If we modify the existing code without affecting the client code, then there is no breach of the open closure principle.

Extension points that are open for extensions do not have extension points

The Tradeprocessorclient class is directly dependent on the TradeProcessor class. When it comes to a new requirement to change the TradeProcessor class, a new type (TRADEPROCESSOR2) is created to implement the new functionality proposed by the requirements in order not to alter the original type. But the side effect of this change is that you have to change the Tradeprocessorclient class so that you can rely on the new TradeProcessor2 class.

If changes to existing code do not affect the client, then you do not need to create a new type. But if the changes to the existing code change the signature of the TradeProcessor class method, it is not a simple change to the class implementation, but a change to the interface. because the client is always tightly coupled to the interface of the service, any changes to the interface will cause changes to the client code.

Virtual method

Another implementation of the TradeProcessor class contains an extensibility point: Processtrades is a virtual method.

Any class with a virtual method member is open to the outside, and this extension is done by inheritance. You can modify the Processtrades method of its subclasses without altering the original TradeProcessor class source code. At this time, the Tradeprocessorclient class does not need to be changed, you can use polymorphic to provide the client with a new version of the TradeProcessor2 class instance.

However, there are limits to the extent to which virtual methods can be re-implemented. The base class can be accessed in a subclass, so you can call the Processtrades method of the TradeProcessor class directly, but you cannot alter any code within the method. Either call the base class method in the subclass method and implement the new attribute before and after it, or completely re-implement the subclass's method. The virtual method has no intermediate state . In addition, subclasses can access only the protected and public members of the base class, and if there are many child classes in the base class that have no access to private members, it may be necessary to modify the base class implementation. However, this would violate the principle of open closure.

Abstract methods

Another more flexible extension point to use to implement inheritance is an abstract approach.

The client relies on the abstract base class, so providing any specific subclass (or subclass to support the new requirement) will not violate the open closure principle for the client.

Interface inheritance

The last extension point is another option for implementing inheritance: Interface inheritance. The client delegate interface supersedes the client's dependency on the class.

interface inheritance is much better than implementing inheritance . Based on implementation inheritance, all subclasses (both present and future) are clients of the base class. The change to add a new member to the top node of the inheritance graph affects all members under that hierarchy, and the interface is much more flexible than the class. This is certainly not to say that the virtual methods that implement inheritance and the extensibility points provided by abstract methods are of little use, but they do not provide the same kind of adaptive capabilities as interfaces.

Prevent variation

Although we already know the way to implement extension points, should we keep the extension points everywhere? Preventing mutation is another important criterion related to the open closure principle:

Identify predictable points of change and create a stable interface around them.

Predictable changes

To identify requirements that are likely to change or to implement particularly troublesome sections of code , and then hide them behind extension points.

A stable interface

The greatest advantage of a dependent interface is that the likelihood of an interface change is much smaller than the implementation. all interfaces used to express the extension point should be stable . Because the client is directly dependent on the interface, if the interface changes, the client must also make corresponding changes.

At last

By ensuring that code is closed to the extension open for modification, you can effectively block changes to existing classes later on, because the next coder can only anchor the newly created class on the extension point you reserved. The code can be rigid, almost impossible to scale and refine, and the code can be smooth, with plenty of extensibility points to prepare for new requirements. There is nothing wrong with both options, just to choose and apply them in a specific scenario.

Reference

"C # Agile Development Practices"

Coderfocus

Public Number:

Statement: This article for Bo Master Learning sentiment Summary, the level is limited, if improper, welcome correction. If you think it's good, just click on the "recommend" button below, thanks for your support. Please specify the author and source of the reference.