C # Open and closed principles

Software entities (Classes,modules,functions etc) should open for extension, but close for modification.

What does that mean.

The so-called open closure principle is that software entities should be developed to expand, but to modify the closed. The principle of open closure is the core of all object-oriented principles. The goal of software design itself is to encapsulate change, reduce coupling, and open closed principle is the most direct embodiment of this goal.

The principle of open closure is mainly embodied in two aspects:

Openness to expansion means that existing code can be extended to accommodate new situations when new requirements or changes are made.

Closing a modification means that once the class has been designed, it can work independently, without making any changes to the class.

Why should we use the principle of open closure?

Software requirements are always changing, there is no software in the world is unchanged, so for software designers, must not need to modify the original system, to achieve flexible system expansion.

How to be open to expansion, to the modification of the closed.

The core idea of realizing open closure is to abstract programming, but not to specific programming, because abstract is relatively stable. Let class rely on fixed abstraction, so it is closed to modification, and through object-oriented inheritance and polymorphism mechanism, we can inherit the abstract body, rewrite its method to change the intrinsic behavior, realize new extension method, so it is open for extension.

A class that violates this principle must be improved by refactoring. The design patterns commonly used in implementation include template method mode and strategy mode. Encapsulation changes are an important means of achieving this principle, and encapsulate the often changing state as a class.

Take the bank salesman as an example

The design of OCP is not implemented:

public class Bankprocess

{//Deposit

public void Deposite () {}

Withdrawal

public void Withdraw () {}

Transfer

public void Transfer () {}

}

public class Bankstaff

{

Private bankprocess Bankpro = new bankprocess ();

public void Bankhandle (client client)

{

Switch (client. Type)

{//Deposit

Case "Deposite":

Bankpro. Deposite ();

Break

Withdrawal

Case "Withdraw":

Bankpro. Withdraw ();

Break

Transfer

Case "Transfer":

Bankpro. Transfer ();

Break

}

}

}

This design is obviously a problem, the current design only deposits, withdrawals and transfer three functions, in the future if the business increased, such as the increase in the subscription fund functions, financial functions, you must modify the Bankprocess business class. Our analysis of the above design can not find that the inability to encapsulate the business in a class, violating the principle of a single responsibility, and new requirements occur, the need to modify the existing code violates the open closure principle.

From the perspective of open and closed, the most likely extension of the banking system is the increase or change of business functions. The business process should be implemented as part of the extension. When there are new features, there is no need to comb the existing business, and then the system to make big changes.

How to achieve the coupling and flexibility of both.

That is abstraction, the business function abstract as an interface, when the salesman depends on the fixed abstraction, the modification is closed, and through inheritance and polymorphism inheritance, from the abstract body to extend the new implementation, is to expand the open.

The following is a design that conforms to the OCP:

First declare a business processing interface

public interface ibankprocess{void Process ();}

public class Depositprocess:ibankprocess

{

public void Process ()

{//Transact deposit Business

Console.WriteLine ("Process deposit");

}

}

public class Withdrawprocess:ibankprocess

{

public void Process ()

{//To handle the withdrawal business

Console.WriteLine ("Process withdraw");

}

}

public class Transferprocess:ibankprocess

{

public void Process ()

{//Transfer Transaction

Console.WriteLine ("Process Transfer");

}

}

public class Bankstaff

{

Private ibankprocess Bankpro = null;

public void Bankhandle (client client)

{

Switch (client. Type)

{//Deposit

Case "Deposit":

Userproc = new Deposituser ();

Break

Transfer

Case "Transfer":

Userproc = new Transferuser ();

Break

Withdrawal

Case "Withdraw":

Userproc = new Withdrawuser ();

Break

}

Userproc.process ();

}

}

In this way, when the business changes, only need to modify the corresponding business implementation classes can be, other unrelated businesses do not have to modify. When the business increases, just add business to the implementation on it.

Design recommendations:

The principle of open closure is the most important design principle, and the principle of Liskov substitution and synthesis/aggregation reuse provide guarantee for the open closure principle.

It can be reconstructed by template method mode and strategy mode, and the design idea of extending and opening is realized.

Encapsulation change is an important means to realize the open closure principle, and it is generally encapsulated as an abstraction for the frequently changing state, such as the Ibankprocess interface in the banking business.

Reject the misuse of abstractions and abstract only the parts that are constantly changing.