How to adhere to the open-closed principle in practice

Question

I understand the intent of the open-closed principle. It's meant to reduce the risk of breaking something that already works while modifying it, by telling you to try to extend without modifying.

However, I had some trouble understanding how this principle is applied in practice. To my understanding, there are two ways to apply it. Beofore and after a possible change:

1. Before: program to abstractions and 'predict the future' as much as you can. For example, a method drive(Car car) will have to change if Motorcycles are added to the system in the future, so it probably violates OCP. But the method drive(MotorVehicle vehicle) is less likely to have to change in the future, so it adheres to OCP.

   However, it's quite difficult to predict the future and know in advance what changes are going to be made to the system.

2. After: when a change is needed, extend a class instead of modifying it's current code.

Practice #1 isn't hard to understand. However it's practice #2 that I'm having trouble understanding how to apply.

For example (I took it from a video on YouTube): let's say we have a method in a class that accepts CreditCard objects: makePayment(CraditCard card). One day Vouchers are added to the system. This method doesn't support them so it has to be modified.

When implementing the method in the first place we failed to predict the future and program in more abstract terms (e.g. makePayment(Payment pay), so now we have to change the existing code.

Practice #2 says we should add the functionality by extending instead of modifying. What does that mean? Should I subclass the existing class instead of simply changing it's existing code? Should I make some kind of wrapper around it just to avoid rewriting code?

Or does the principle not even refer to 'how to correctly modify/add functionality', but rather refers to 'how to avoid having to make changes in the first place (i.e. program to abstractions)?

Answer 1

Design principles always have to be balanced against each other. You can't predict the future, and most programmers do it horribly when they try. That's why we have the rule of three, which is primarily about duplication, but applies to refactoring for any other design principles as well.

When you only have one implementation of an interface, you don't need to care much about OCP, unless it's crystal clear where any extensions would take place. In fact, you often lose clarity when trying to over-design in this situation. When you extend it once, you refactor to make it OCP friendly if that's the easiest and clearest way to do it. When you extend it to a third implementation, you make sure to refactor it taking OCP into account, even if it requires a little more effort.

In practice, when you only have two implementations, refactoring when you add a third is usually not too difficult. It's when you let it grow past that point that it becomes troublesome to maintain.

Answer 2

I understand the intent of the open-closed principle. It's meant to reduce the risk of breaking something that already works while modifying it, by telling you to try to extend without modifying.

It is also about not breaking all the objects that rely on that method by not changing the behavior of already existing objects. Once an object has advertised behavior changing it is risky as you are altering the known and expected behavior of the object without knowing exactly what other objects expect that behavior.

What does that mean? Should I subclass the existing class instead of simply changing it's existing code?

Yup.

"Only accepts credit cards" is defined as part of the behavior of that class, via its public interface. The programmer has declared to the world that this object's method only takes credit cards. She did it using a kinda not particularly clear method name, but its done. The rest of the system is relying on this.

That might have made sense at the time, but now if it needs to change now you should make a new class that accepts things other than credit cards.

New behavior = new class

As an aside - A good way of predicting the future is to think about the name you have given a method. Have you given a really general sounding method name like makePayment to a method with specific rules in the method as to exactly what payment it can make? That is a code smell. If you have specific rules these should be made clear from the method name - makePayment should be makeCreditCardPayment. Do this when you are writing the object the first time and other programmers will thank you for it.

Answer 3

I think you are looking too far into the future. Solve the current problem in a flexible way which adheres to open/closed.

Let's say you need to implement a drive(Car car) method. Depending on your language you have a couple of options.

• For languages which support overloading (C++), then just use drive(const Car& car)

  At some point later you might need drive(const Motorcycle& motorcycle), but it won't interfere with drive(const Car& car). No problem!

• For languages which don't support overloading (Objective C), then include the type name in the method -driveCar:(Car *)car.

  At some point later you might need -driveMotorcycle:(Motorcycle *)motorcycle, but again, it won't interfere.

This allows drive(Car car) to be closed to modification, but is open to extending to other vehicle types. This minimalist future planning which allows you to get work done today, but keeps you from blocking yourself in the future.

Trying to imagine the most basic types you need can lead to infinite regress. What happens when you want to drive a Segue, a bicycle or a Jumbo jet. How do you construct a single generic abstract type which can account for all devices people get into and use for mobility?