Open / Closed principle - How to call the new versions?

Question

I'm trying to grasp the Open/Closed principle (in my case for PHP, but that shouln't really make a difference).

The way i understand it is that a class is never open for modification. Only for bug fixing. If i wanted to add new code to the class, then i'd have to create a new one and extend the 'old' class. That's the only way i can add new code to it.

In a way i can see the advantages of this. Because basically you create some sort of versioning system, where old code always work, but you can always try to use the new classes too.

But how does this work in practice? I mean, suppose i have the following class:

class MyObject
{
    public function doSomething()
    {
        echo 'Im doing something';
    }
}

So somewhere i'm probably instantiating this class:

$obj = new MyObject();

But then i decide that it's good to have another method in that object. So i can do something else too. According to the OCP i can't modify the class. So i have to create a new one, which extends to old one right?

First problem. How do i call the new class? Because it isn't really a complete new object. Like. a User object is a User object. I can't suddenly give it completely diffent name just because it needs another method. Anyway, i create the new class:

class MyNewObject extends MyObject
{
    public function doSomethingElse()
    {
        echo 'Im doing something else now';
    }
}

Now this also means i have to change the line of code where i instantiated the "MyObject" class and replace it with the "MyNewObject" class, right..? And if that's done in more than one place, then i have to search through my source code... (Think about a method in a controller class, which almost always uses the 'new' keyword to instantiate certain classes).

The same basically applies to inheritance. I'd have to find each class the inherits the old class and have to replace that with the new class.

---

So basically my questions are:

How do you name the new classes which have the new methods? Just becasue i added some new functionality, doesn't mean i can give the class a whole new name...

And what if the 'old' classs is instantiated (or inherited) from multiple places. Then i'd have to find all of those places... Where's the gain?

Khelat

$x = new MyObj_version_3.14159265()? mmmmm. pie. – Upstanding

Note that there are two ways of interpreting the Open/closed principle. You seem to be thinking primarily of the older one (Meyers), whereas that use case is usually handled by delegation nowadays. – Biconcave

It would be easier to answer this question with a more realistic example. Naming, etc. would be more obvious I think. – Jonajonah

Answer 1

The Open Closed Principle isn't intended to be used as a kind of version control system. If you really need to make changes to the class, then go ahead and make those changes. You don't need to create new classes and change all the places that instantiated the old one.

The point of the Open Closed Principle is that a well-designed system shouldn't require you to change existing functionality in order to add new functionality. If you are adding a new class to the system, you shouldn't need to search through all your code to find the places where you need to reference that class or have special cases for it.

If the design of your class isn't flexible enough to handle some new piece of functionality, then by all means change the code in your class. But when you change the code, make it flexible so you can handle similar changes in the future without code changes. It's meant to be a design policy not a set of handcuffs to prevent you from making changes. With good design decisions, over time your existing code will require fewer and fewer changes when you add new functionality to the system. It's an iterative process.

Immunity

Answer 2

I would argue that by adding a function, you're not modifying the class behavior.

In all the instances where doSomething() is currently being called in your app, simply by adding doSomethingElse() to the class will have no effect. Since you're not changing doSomething(), the behavior is the same as it was before.

Once you determine that your doSomething() implementation isn't cutting it for certain circumstances, you can extend the class and override doSometing(). Again, the original still behaves the same as it always did, but now you have a new doSomething() to work with also.

I realize that this goes against the strict definition of open/closed, but this is the real world, and that's how I interpreted that principle in my code.

Zibet

I agree, adding a new method isn't that breaking. Not in the example that i gave. But if i need to do some code breaking changes to a method,then i'd have to create a new class which does that new thing i want. But then my two questions still remain. How do i name the new class? And does that mean i have to search through my entire code to find out where i instantiated the old class so i can change it with the new one? The last one is what bothers me the most actually... Therfore i don't see benefit in this principle. – Khelat

You should think of this the other way around: if your subclass has no obvious name then perhaps you shouldn't be making it! Subclasses should not be used to fix broken classes--the broken class should be fixed, and calling code that depends on broken behavior should be fixed too. (That said, sometimes you need to subclass to fix a broken class, but that's usually because you can't control the parent class or its calling code.) – Biconcave

BTW, two good reasons for making a subclass: to make a new implementation of a more abstract base class (polymorphic inheritance), or to create a subtype which has extra functionality but which obeys the Liskov Substitution Principle. In both cases a new name should be obvious. – Biconcave

Answer 3

You need to create a constructor in your MyNewObject class which calls the parent class' constructor:

function __construct() {

    parent::__construct();

}

This way you can instantiate the new class and still access all the functionality of the extended one.

You can then also override any function in the parent class (as long as it is not marked final of course).

So you could do:

$newObj = new MyNewObject();

$newObj->doSomething();

$newObj->doSomethingElse();

Shenyang

Yes, i know i have to call the parents constructor. Otherwise the inheritence wouldn't be of much use :) --- But in you're example you're also creating an instance of "MyNewObject" instead of "MyObject". Which makes sence ofcourse, because you want to use the new functionality. But that also means you have to change every line in your code where you once instantiated "MyObject". You'd have to change that now to "MyNewObject". This doesn't really feel quite OO to me if you have to search through your entire code to change the old instantiations to new the one. – Khelat

Yeah I see your point. Forgive me for assuming you were a bit new to OOP. – Shenyang