How `open/closed principle` can help avoiding to redeploy assemblies?

Question

I've recently read a nice, easy to understand article about open/closed principle. And I've been wondered by the following experience:

In a real world scenario where the code base is ten, a hundred or a thousand times larger and modifying the class means redeploying it’s assembly/package to five different servers that can be a pretty big problem. Oh, and in the real world Aldford would have changed the requirements five more times since you read the last sentence :-)

How open/closed principle can help avoiding to redeploy assemblies?

Answer 1

As you know the open/close principle can be accomplished in different ways depending on the scenario. For the scenario of late binding of assembly, the open/close principle would mean for me to program against interfaces for the parts in the code where this minior/major changes may occur in time.

More info about late binding: https://en.wikipedia.org/wiki/Late_binding

Shortly late binding is in the context i am mentioning is ability to choose dll to be loaded at runtime in our program.

I will try to explain in with an example. If we'have application that is huge and minior part of the functionality which provide is making some calculation (let say it adds numbers)

ICalculator
{
    int Add(int a, int b);
}

The dll that contains the calculator interface is Application.Calcualtion.dll and the code using the ICalculator interface in the dll could have some Boostrapp/Init function that will instantiate concrete implementation of the calculator.

Here come's the late binding.

Instead of using something like Calculator = new ConcreteCalculator(), you can load dll with implementation of the ICalculator interface from specific location .

using Assemnly.LoadFile(path: "....")

then you can query the assembly for the interface using somthing like this

var calculatorType = assembly.ExportedTypes.OfType<ICalculator>().Single();

Usually the dll can be loaded from some specific location. So when the calculator implementation must be changed then the update of the application can only deploy a new dll with ICalculator implementation to the specific location you boostrap the dll.

The late binding approach looked from another angle just Dependency Inversion principle, but also allows to extend/change the behaviour of your calculation functionality without changing the original code in the application.

Hope this helps.