What is the meaning and reasoning behind the Open/Closed Principle?

Question

The Open/Closed Principle states that software entities (classes, modules, etc.) should be open for extension, but closed for modification. What does this mean, and why is i

Answer 1

Software entities should be open for extension but closed for modification

That means any class or module should be written in a way that it can be used as is, can be extended, but neve modified

Bad Example in Javascript

var juiceTypes = ['Mango','Apple','Lemon'];
function juiceMaker(type){
    if(juiceTypes.indexOf(type)!=-1)
        console.log('Here is your juice, Have a nice day');
    else
        console.log('sorry, Error happned');
}

exports.makeJuice = juiceMaker;

Now if you want to add Another Juice type, you have to edit the module itself, By this way, we are breaking OCP .

Good Example in Javascript

var juiceTypes = [];
function juiceMaker(type){
    if(juiceTypes.indexOf(type)!=-1)
        console.log('Here is your juice, Have a nice day');
    else
        console.log('sorry, Error happned');
}
function addType(typeName){
    if(juiceTypes.indexOf(typeName)==-1)
        juiceTypes.push(typeName);
}
function removeType(typeName){
  let index = juiceTypes.indexOf(typeName)
    if(index!==-1)
        juiceTypes.splice(index,1);
}

exports.makeJuice = juiceMaker;
exports.addType = addType;
exports.removeType = removeType;

Now, you can add new juice types from outside the module without editing the same module.

Answer 2

Open Closed Principle is very important in object oriented programming and it's one of the SOLID principles.

As per this, a class should be open for extension and closed for modification. Let us understand why.

class Rectangle {
    public int width;
    public int lenth;
}

class Circle {
    public int radius;
}

class AreaService {
    public int areaForRectangle(Rectangle rectangle) {
        return rectangle.width * rectangle.lenth;
    }

    public int areaForCircle(Circle circle) {
        return (22 / 7) * circle.radius * circle.radius;
    }
}

If you look at the above design, we can clearly observe that it's not following Open/Closed Principle. Whenever there is a new shape(Tiangle, Square etc.), AreaService has to be modified.

With Open/Closed Principle:

interface Shape{
    int area();
}

class Rectangle implements Shape{
    public int width;
    public int lenth;

    @Override
    public int area() {
        return lenth * width;
    }
}

class Cirle implements Shape{
    public int radius;

    @Override
    public int area() {
        return (22/7) * radius * radius;
    }
}

class AreaService {
    int area(Shape shape) {
        return shape.area();
    }
}

Whenever there is new shape like Triangle, Square etc. you can easily accommodate the new shapes without modifying existing classes. With this design, we can ensure that existing code doesn't impact.

Answer 3

It's the answer to the fragile base class problem, which says that seemingly innocent modifications to base classes may have unintended consequences to inheritors that depended on the previous behavior. So you have to be careful to encapsulate what you don't want relied upon so that the derived classes will obey the contracts defined by the base class. And once inheritors exist, you have to be really careful with what you change in the base class.

Answer 4

It means that you should put new code in new classes/modules. Existing code should be modified only for bug fixing. New classes can reuse existing code via inheritance.

Open/closed principle is intended to mitigate risk when introducing new functionality. Since you don't modify existing code you can be assured that it wouldn't be broken. It reduces maintenance cost and increases product stability.

Answer 5

This means that the OO software should be built upon, but not changed intrinsically. This is good because it ensures reliable, predictable performance from the base classes.

Answer 6

More specifically than DaveK, it usually means that if you want to add additional functionality, or change the functionality of a class, create a subclass instead of changing the original. This way, anyone using the parent class does not have to worry about it changing later on. Basically, it's all about backwards compatibility.

Another really important principle of object-oriented design is loose coupling through a method interface. If the change you want to make does not affect the existing interface, it really is pretty safe to change. For example, to make an algorithm more efficient. Object-oriented principles need to be tempered by common sense too :)