Aaron Proctor

The incoherent braindump of a software developer

Open/Closed Principle

This is part 2 of a series of blog posts on the SOLID principles – five fundamental principles of object-oriented software design.

The Open/Closed Principle

The Open/Closed Principle states:

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

This suggests that a class should facilitate new functionality by extension rather than modification. It has obvious advantages when it comes to changing requirements – by leaving existing functionality untouched, it reduces the likelihood of new development causing ripple effects.

But how do we design our object model to achieve this?

Let’s suppose we add a new type of Enemy to the game, the Boss, which is more difficult to kill. We could do this with an Enum:

And then modify our Enemy to have a hit points property and PlayerAttack method to utilise the new type:

Not only have we made the code more complex and error-prone, but we’ve also modified the Enemy class and PlayerAttack class despite those concepts not having changed in the requirements.

Instead, let’s try extending the Enemy class to create a new type, Boss:

Now we have encapsulated the new requirements for a Boss without touching the Enemy class. Using inheritance or abstractions in place of enums is good practice – certainly any time you’re using a ‘switch’ or ‘if’ statement with an enum it should be treated with suspicion.

Post a comment