To understand OCP you must first internalize the Single Responsibility Principle (SRP) and the concept of the Responsibility and Dependency Principle (RDP).

A Class or Method is, by nature, created to perform some application or assembly work. This Class of Method generally has a requirement that the calling Method expects to be supported:

The Requirement is its Responsibility

The Calling Software Entity is generally asking for a very specific response

The body of the called Methods ONLY Responsibility is to consume the Request Parameters

… And Deliver the Expected Response Object with all the requires child objects and properties

The Dependencies should be abstracted from the Responsibility using Private Class Helper Methods if the dependency is a One and Only One relationship to the Class.

If other Software Entities can reuse the helper method, it should be refactored into a Common Utility Class as a public Static Helper Method 

This concept is defined in The Modern Developer as the Responsibility and Dependency Principle (RDP):

Do Your Job and Only Your Job

… Let Every Else do Their Job

Using RDP for the understanding and identification of the Responsibilities and the Dependencies in Software Entities supports SRP, DRY and OCP natively.

When complying with Single Responsibility Principle your objective is to create Classes and Methods that keeps its focus on the outcome of the behavior the “What”, not the details of “How” that behavior is accomplished.

The “What” will not change throughout the life cycle of the Software Entity but the “How” very well may change.

Using private Class level and public Common Assembly level Helper Methods that define the “How” will abstract away the details of the outcome from the responsibility of the software entity.

These are the areas of change. Helpers that are used for code reuse are great for encapsulating functionality that is Open for extension but allows the consuming type to be closed for modification.

There is a major performance advantage to this Run-time philosophy as well.

The Just In-Time Compiler (JIT) looks for short and simple methods that are frequently used, helper methods, and can “In-lined” for better performance.

In-lining substitutes the body of a function for the Signature of the function call only when Required

The JIT uses Registers and Pointers to catalog the signatures of small methods such as those used to abstract away the details of a Class’s responsibility.

Smaller and simpler functions make it easier for the JIT compiler to support “Enregistration”

This is the process of selecting which local variables can be stored in registers rather than on the stack.

This register is a single block of Managed Heap memory that can access through pointers possibly hundreds or thousands of discrete method variables.

It will only compile for the Common Language Run-time (CLR) when actually called.

This means if a Case statement or Nested If conditionals are never used

… The CLR will never see the code. This saves memory and CPU cycles.

If you cannot understand the method’s contract with the calling class method quickly then the method has blurred its “What” with the “How”.

You should be able to Define what the Method is Doing

… Simply by its Method Parameters and its Response Object

The process it uses to complete the request defines its dependencies as the implementation of the request; this is NOT its responsibility

Process Details should be Abstracted Code that can Easily Change Over Time

1. Lengthy Methods – Code that take more than thirty seconds to understand its function is generally a OCP code smell
2. Nested If Statements – Conditionals that do not directly support the method’s responsibility is always a OCP code smell.
3. Logic such as Switch Cases Code Blocks– Case statements are Process Logic. These activities support the “How” of the Methods Responsibility and is a candidate for Helper Method abstraction
4. Algorithms inside the Called method – These Code statements are prime candidates for change over the life cycle of the method. All calculations and complex algorithms should always be abstracted into private or public helper methods for reuse.

Issues with this code:

• Solution is not Extensible – Only supports the current requirement
• The Methods has Four Responsibilities – Three of the responsibilities need OCP to comply with SRP
• Class Name Is PrintData – The Format Selection dependency, the Device Type Selection dependency, and the Data Acquisition dependency are not part of the Print Data request. The Console Display code is the only responsibility of the class: All others are OCP Dependency refactoring

The key take away from the above code is the first console application class.

Every line of code has a direct relationship to the Single Responsibility of the class:

Print Information to the Console Screen

The region holds the code for the responsibility method: PrintDataToOutputDevice()

All the dependencies have been extended and encapsulated in their own responsibilities using the three method on lines 11 – 13.