Principles of Open and Closed Programming (OCP)

Professor Zhou Ligong's extensive efforts in writing the books "Programming and Data Structure" and "Programming for AMetal Framework and Interface (I)" sparked a significant learning trend within the electronics industry. With Professor Zhou's authorization, this public account has serialized the content of "Programming and Data Structure" and is now sharing it with the community.

The second chapter focuses on programming techniques. This article discusses section 2.4.3: The Open-Closed Principle (OCP).

> > > 2.4.3 Open-Closed Principle (OCP)

The Open-Closed Principle (OCP) is one of the fundamental principles of agile software development. It states that a module should be "open for extension but closed for modification." For example, a USB port can accept new devices without requiring any changes to its existing structure. A computer with a USB port is considered open for extensions (new devices) and closed for modifications (the interface remains unchanged). When a design follows OCP, it allows for expansion by adding new code rather than modifying existing code. Even if the internal implementation of a module changes, the external interface should remain stable. The goal is to isolate changes and make the system more maintainable and scalable.

To apply OCP effectively, we need to abstract the software. Only an abstract interface with commonality can allow for multiple concrete implementations. The interface should be placed on the client side, not on the implementation side, so that the client can interact with the abstraction without being affected by changes in the underlying implementation.

Let’s consider a stack that only accepts values between 0 and 9, i.e., min=0 and max=9. According to OCP, we should create a function called pushWithRangeCheck() that calls the original push() function. The range validation logic is included in this function, while the actual value, min, and max are passed as parameters. Its function prototype would look like this:

If the value is invalid, the function returns false; otherwise, it calls push(). If the stack is not full, it returns true; otherwise, false. This is shown in Listing 2.36.

Listing 2.36 Range Value Verifier Sample Program (1)

By following OCP, future changes only require adding new code instead of modifying existing code. However, when multiple checkers are needed, passing too many parameters can become cumbersome. To solve this, we can encapsulate min and max into a Range type structure, which simplifies the function signature.

According to OCP, we need to write a pushWithRangeCheck() function that extends the push function. The range value verifier sample program is shown in Listing 2.37.

Listing 2.37 Range Value Verifier Sample Program (2)

If we want to add another checker, such as a parity check, we can define a new OddEven type structure and write a corresponding function, pushWithOddEvenCheck(), which extends the push function.

To prevent direct access to the internal data, we define a check interface function as shown below:

Since both the range and parity check functions use pointers to the current object, we can generalize them to void *pData, allowing for more flexible usage.

Whether it's a range check or a parity check, the core is validating input. Therefore, we can share a function pointer for all validators. Its function prototype is as follows:

For better readability, the universal validator interface is shown in Listing 2.38.

Listing 2.38 Common Validator Interface (validator.h)

Although we cannot predict what checkers will be added in the future, the caller knows how to use them. By separating the range and parity checkers into individual functions, we can write a generic pushWithValidate() function that calls the appropriate function pointer, without caring about the specific implementation. The general validator sample program using the validator.h interface is detailed in Listing 2.39.

Listing 2.39 General Validator Sample Program