2

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?

Tyress
  • 3,573
  • 2
  • 22
  • 45
StepUp
  • 36,391
  • 15
  • 88
  • 148
  • 5
    i think it's misleading for the article to suggest that the key benefit of open-closed is in allowing partial deployment. The real benefit is in ease of extension/modification. To be honest the article kind of reads as though the author understands how to abide by the principle but hasn't fully grasped the reasons for it. – Ant P Jan 25 '17 at 08:48
  • 1
    I think it would actually be interesting to see how ocp is used for partial deployment, if it is. – Tyress Jan 25 '17 at 08:57

1 Answers1

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.

vasil oreshenski
  • 2,788
  • 1
  • 14
  • 21