Principles of Open and Closed Programming (OCP)

Professor Zhou Ligong's years of hard work "Programming and Data Structure" and "Programming for AMetal Framework and Interface (I)", after the publication of the book content, set off a learning boom in the electronics industry. Authorized by Professor Zhou Ligong, this public number has serialized the contents of the book "Programming and Data Structure" and is willing to share it.

The second chapter is programming technology. This article is the 2.4.3 Open and Close Principle (OCP) .

> > > 2.4.3 Open and Close Principle (OCP)

Open-Closed Princple (OCP) is one of the basic principles of agile software development. A module should be "open to extensions and closed to modifications." For example, a USB port can be extended without any modification. A new device can be accepted, so for a USB application device, a computer with a USB port is open and closed for modification. When the design follows the OCP principle, it can be extended by adding new code instead of modifying the existing code. For example, even if the internal implementation of a module changes, the external interface cannot be changed. The purpose is to isolate the changes. OCP usually requires us to abstract the software, because only the abstract interface with commonality will have the possibility of concrete implementation. Where is the interface placed? It should be placed on the client side, not on the side of the implementation.

Assume that only the value of 0~9 is allowed to be pushed onto the stack, ie min=0, max=9. According to the OCP principle, you need to write a function pushWithRangeCheck() that calls the push() function. The commonality - the legitimacy judgment of the range value is included in the function body, and the variable value values, min and max are dealt with by the formal parameters. Its function prototype is:

If the value is illegal, false is returned; if the value is valid, push() is called. At this point, if the stack is not full, it returns true, otherwise it returns false, as shown in Listing 2.36.

Listing 2.36 Range Value Verifier Sample Program (1)

Thus, if the OCP is applied correctly, then if you make the same changes later, you only need to add new code without having to change the code that is already running. If only 1-2 checkers are needed, the above method is very straightforward. When a combination of multiple validators is required, the above method passes too many parameters, and each time the push is passed, the allowed range parameters are passed. If you separate min and max into a Range type structure, you can avoid the above problem:

According to the OCP opening and closing principle, you need to write a pushWithRangeCheck() function that extends the push function. The scope value checker sample program is shown in Listing 2.37.

Listing 2.37 Range Value Verifier Sample Program (2)

If you add another parity checker, you need to determine whether the data pushed to the stack is even, and create the corresponding OddEven type structure as follows:

According to the OCP opening and closing principle, you need to write a pushWithOddEvenCheck() that extends the push function. which is:

In order to avoid the user directly operating the member, you need to define the corresponding check interface function. which is:

Since both the range value check function and the even check function have a pointer to the current object, the special Range *pRange and OddEven *pOddEven can be generalized to void *pData. which is:

Whether it is a range value check or an even check, the commonality is to verify the input parameters, so a function pointer can be shared. Its function prototype is as follows:

For ease of reading, the interface to the universal validator is shown as shown in Listing 2.38.

Listing 2.38 Common Validator Interface (validator.h)

Although it is impossible to predict what checker will be supported, the caller knows, so you can separate the range value verifier and parity function into separate functions, write a generic pushWithValidate() function, and call the corresponding function pointer. The checksum function, and do not care about the implementation of the specific validator, the general checker sample program using the validator.h interface is detailed in Listing 2.39.

Listing 2.39 General Validator Sample Program