Software modules should be open for extension but closed for modification.

Dr Bertrand Meyer - Object-Oriented Software Construction, 1988

Where
module = A class, function or method

It should be possible to change the behaviour of a module without editing its source code.

Why Should Code Be Closed to Modification?

• Less likely to introduce bugs in code we do not touch to redeploy.
• Less likely to break dependent code when we do not have to deploy updates.
• This produces fewer conditionals in modules, that are open to extension, resulting in simpler code.
• Remember bug fixing modules is OK.

Balancing Abstraction and Concreteness

Abstraction adds complexity.

We require applications that can flex in the ways that we will need them to.

Therefore we need to predict where variation is needed and apply abstractions.

How Can You Predict Future Changes?

• Start concrete.
• Modify the code the first time or two.
• By the third modification, consider making the code open to extension

Typical Approaches to OCP

• Parameters
• Inheritance
• Composition/Injection
• Extension Methods (C# feature)

Inheritance

public class DoOneThing
{
    public virtual void Execute()
    {
        Console.WriteLine("Hello world!")
    }
}

// Override Class
public class DoAnotherThing : DoOneThing
{
    public override void Execute()
    {
        Console.WriteLine("Goodbye world!")
    }
}

Composition/Injection

public class DoOneThing
{
    private readonly MessageService _messageService;

    // We inject our message service into the class
    // through the constructor.
    public DoOneThing(MessageService messageService)
    {
        _messageService = messageService;
    {

    public void Execute()
    {
        _messageService.Write("Hello world!")
    }
}

We could have instantiated the MessageService within the constructor, but that would have glued it to the consumer.

Prefer Implementing New Features in New Classes

This is especially true for large legacy applications.

Why Use a New Class?

• Design class to suit the problem at hand
• Nothing in the current system depends on it
• Can add behaviour without touching existing code
• Can follow Single Responsibility Principle
• Can be unit-tested

Packages and Libraries

These are open to extension but closed to modification.

Open to Extension

• Consumers should be able to extend the package to suit their own needs.

Closed for Modification

• Consumers are not able to modify package contents.
• Should not break existing consumers' solutions when new behaviours are added.

Resources

• Why the Open Closed Principle is the one you need to know but don’t
• Open Closed Priniple by Robet Martin
• Open Closed Principle by Jon Skeet

Key Takeaways

• Solve the problem first using simple, concrete code.
• Identify the kinds of changes the application is likely to continue needing.
• Modify code to be extensible along the axis of change you've identified.
  • Without the need to modify its source each time.

Other Links

stackify.com/solid-design-open-closed-principle