When designing a module, the module should be extended without modification, so that the module's behavior can be changed without modifying the source code.
Statement:
Software entities (classes, modules, functions, etc.) should be extensible and can be modified without modification, or rather, function entities should:
(1) is open to expansion
When the requirements of the application change, we can extend the module so that it has the new behavior to satisfy the change. That is, we can change the function of the module
(2) The change is closed
When you extend a module, you do not have to change the source code or binary code that is already in the module.
Analysis:
The world is changing (and changing quickly), and software is an abstraction of reality. ----> software must be scalable.
If any modification needs to change the existing code, it may lead to a systemic phenomenon, leading to avalanche effect, so that the quality of software significantly decreased.
The key to implementing OCP is abstraction:
Example 1: A client that is neither open nor closed:
Problem:
Both client and server are concrete classes, and interfaces are not decoupled from implementations. If we want the client to invoke a new server class, then we have to modify the client's source code. resulting in a series of issues such as compiling, linking, and deploying.
View Plainprint? Class client{server& s; Public:client (server& SER): s (SER) {} void Useserver () {s.serverfunc (); } }; View Plainprint? class server{int serverdata; Public: