Open-Closed Principle

Some theory

Another rule under the letter "O" in the acronym SOLID is the title open-closed rule. The content of the rule is very simple and seems downright trivial:

Before giving an example, I will briefly write about why this principle is important. Writing software very often requires introducing various changes. They result from a change in business logic or the need to refactor the code. If the introduction of a new functionality requires significant changes to the code, it may turn out that another person using the functionality elsewhere will lose it.

Some code

Invalid code

Let's follow an example of the code that counts the figure's square. First, an example of a code that breaks the open-closed principle. We create a class of a triangle and then a class that counts the area of the figure.

public class Triangle {
    public float baseLength;
    public float height;
}

public class AreaCalculator {
    public float calculateTriangleArea(Triangle triangle) {
        return triangle.baseLength * triangle.height / 2;
    }
}

Our app works great, but there was a need to add the option to count the area of the circle. We add the class of the circle, then we need to make a change to the class calculating the area of the new figure, and at this point we break the open-closed principle. Our code looks like this:

public class Triangle {
    public float baseLength;
    public float height;
}

public class Circle {
    public float radius;
}

public class AreaCalculator{

    public float calculateTriangleArea(Triangle triangle) {
        return triangle.baseLength * triangle.height / 2;
    }

    public float calculateCircleArea(Circle circle) {
        return 3.14 * circle.radius * circle.radius;
    }
}

Note that adding a new figure forces the modification of another existing class and the implementation of a new method of calculating the area. Let's write our program differently.

Valid code

In order to avoid breaking the rule, it is enough to create an interface that will contain a method of calculating the area. Next, let's establish that each new figure will implement this interface. Then our code will look like this:

public interface Shape {
    public float calculateArea();
}

public class Triangle implements Shape {
    public float baseLength;
    public float height;

    public double calculateArea() {
        return baseLength * height / 2;
    }
}

public class Circle implements Shape {
    public float radius;

    public float calculateArea() {
        return 3.14 * radius * radius;
    }
}

This construction allows us to create a calculator that does not require any interference when adding further figures:

public class AreaCalculator {
    public float calculateShapeArea(Shape shape) {
        return shape.calculateArea();
    }
}

It can therefore be concluded that our calculator is closed to modification and open to extension.

Summary

As you can see, this principle, although apparently simple, is not so obvious in implementation. Sometimes it requires foreseeing potential directions of program development, as well as the ability to distinguish various abstractions. Feel free to read the other articles about the SOLID principles.