Maurizio's blog 3.0

In this post I will speak about the second principle of Object Oriented Design (OOD), i.e. the Open-Closed Principle (OCP). in addition to the first one (SRP)  which I have already spoken in my previous post.

This principle was coined by Bertrand Meyer, the same person who coined the term “design by contract”, to which I devoted an article that you can view on the  UgiDotNet site.

This principle simply states that software entities, i.e. class, “should be opened for extensions but closed for modifications“.

Now, what does it really means ?

We all know that code changes according to changing requirements. When we design a module software, we design it according to certain requirements valid at the time. When requirements change we should be able to extend that software module, i.e. add new features in addition to existing ones, and the latter should not be changed for any reason.

In other words, when we create a module with certain features, that module must be immutable, and immutable means stable.

This principle apparently shows a contradiction: how can something that is immutable be subject to extensions, and then ultimately to change?

The answer lies in the use of abstract classes or interfaces. In fact, you can see it from this point of view: an interface or an abstract class, once created and established the methods and properties with their signatures, must be unalterable, but you can create different concrete classes which implement that interfaces and abstract classes, and then different implementations, and then modify or extend their behavior leaving the contract intact.

In this way, the software module is closed for modifications (the interface doesn’t never change), but is also open for extensions as you can create different implementations.

This principle would imply another principle: it’s necessary to design on interface and not on concrete implementations, otherwise the OCP would inexorably violated.

Some of the principles about the object oriented programming (OOD) deal with design.

This design principles are known with the acronym of SOLID.

SOLID stands for:

(S)ingle Responsibility principle;
(O)pen closed principle;
(L)iskov substitution principle;
(I)nterface segregation principle;
(D)ipendency inversion principle

In my opinion, these principles are very important to understand if we are to achieve the greatest benefits of OOP.

In this post, I’ll speak about the first of these principles, i.e. the Single Responsibility Principle (SRP).
In future posts, I hope, I’ll speak about the others.

The SRP is perhaps the easiest to understand and the easier to violate.
This principle states that a class should have one and only one reason to change (responsibility).
One responsibility is associated with a potential reason for change the code of a class. So, if a class has more than 1 responsibility, also has more than 1 reason for change, and then the class violates the SRP.

For example, consider a interface like this, which is implemented by a hypothetical class that manages documents:

 public interface IDocument
 {
    Document LoadDocument(int id)
    void SaveDocument(Document document)
    decimal GetTotalDocument(int id);
}

What’s wrong with this simple code ?

Apparently nothing, but in terms of design this class violates the SRP, because the first two methods having to do with the persistence, while the third returns the result of a state variable according to a specific business rule, and then has to do with business rules. Thus, this hypothetical class may change if we change repository of persistence and /or if we change the business rules, and thus violates the SRP.

A better approach is to split this class into 2 separate classes, one for each responsibility, i.e.:

 public interface IDocumentPersistence
 {
     Document LoadDocument(int id)
     void SaveDocument(Document document)
 }
 
 public interface IDocumentRules
 {
     decimal GetTotalDocument(int id);
 }
 

The application of this principle maximizes the cohesion between the various parts of an application and minimizes the coupling between the same parts.

In the previous example the two interfaces are likely to be called from different parts of an application and are also subject to change for different reasons, so it is proper to keep them separate.