This is the 21st day of my participation in the August More Text Challenge

OCP open-closed Principle

Well-designed computer software should be easy to extend and resistant to modification

In other words, a good computer system should be easily extensible without modification

The module designed according to the open and close principle has two characteristics:

  1. “Open for extension”, as the requirements of the application change, we can extend the module with new behaviors to meet those changes
  2. “Encapsulation for change” means that you don’t have to change the original code when you extend a module

In fact, this is the fundamental purpose of studying software architecture. If a small extension of the original requirements requires a major modification of the original software system, the architectural design of the system is shown to be a failure

A good software architect will try to minimize, or even zero, changes to old code

This principle may seem contradictory and needs to be extended, but not modified; So how do you implement this principle?

Abstract, interface oriented programming

A module can operate on an abstraction. Because a module depends on a fixed abstraction, it can be turned off for change. It is also possible to extend the behavior of this module by deriving from this abstract body

Client and Server are concrete classes, and client uses server

If a client wants to use another server object, it needs to change where server is used in the client

This is clearly a violation of OCP

In the new design, the ClientInterface interface is added, which is an abstract class with abstract member functions. The Client class uses this abstract class. If we want the Client object to use a different server, we simply derive a new class from the ClientInterface class, and the client does not need to change anything

interface ClientInterface { public void Message(); //Other functions } class Server:ClientInterface { public void Message(); } class Client { ClientInterface ci; public void GetMessage() { ci.Message(); } public void Client(ClientInterface paramCi) { ci=paramCi; }} Public static void Main() {ClientInterface ci = new Server(); // If there is a new Server class above, just replace Server(). Client client = new Client(ci); client.GetMessage(); }Copy the code

OCP is an important principle when designing classes and modules, but it is even more significant at the architectural level.

At design time, you can group code that meets different requirements (SRPS) and then adjust the dependencies between these groups (DiPs)

Is IOC also OCP flavor

OCP is at the heart of object-oriented design. Following this principle brings great benefits of object-oriented technology (flexibility, reusability, and maintainability)

However, it is not necessary to follow this principle whenever you use an object-oriented language. Arbitrarily abstracting every part of your application is also not a good idea. Instead, developers should abstract only those parts of the program that show frequent changes; rejecting immature abstractions is as important as abstraction itself

Why is it advisable to “try” not to violate OCP in a complex piece of software?

The core reason is that a change to an existing logic may affect some of the existing code, resulting in some unforeseen effects. This risk can only be protected by full unit test coverage, but it is difficult to guarantee single-test coverage in real development. OCP’s principles avoid this risk as much as possible, since the old code behaves the same way when the new behavior can only be implemented through new fields/methods

Common Closure Principle (CCP)

CCP extends the “closed” concept of the OPEN closed principle (OCP) by limiting the scope of modifications to a minimal package when they are needed for some reason

All classes in a package should be closed for changes of the same type. A change that affects a package affects all classes in the package. A shorter way to put it is: classes that are modified together should be grouped together (in the same package). If we have to change the code in the application, we want all the changes to happen in one package (change off), not spread across many packages. The CCP principle is to group all classes that need to be modified for the same reason into one package. If two classes are so closely related, physically or conceptually, that they usually change together, they should belong to the same package.

CCP is also a solution to the dreaded anti-pattern of distributed singleton

In the prevailing microservices architecture, decomposition by business capabilities and subdomains, as well as SRP and CCP, is a good way to decompose applications into services