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.

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.

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?