Open Closed -

Open Closed

SOLID was written during the early 90's when changing the code and republishing took a lot of time. Now it just takes minutes to redeploy the code. Also nowadays with the agile way of developing software changes are bound to happen.

We often have this tendency to try to gold-plate things or say, well, we have this specific problem, but if we just set a specific flag here or add an input argument to this function here, we could make this specific thing that we're trying to do into some sort of general purpose solution, and the problem with that is that it tends to lead to coupling and complexity.

 Reused Abstractions Principle. So this is not a principle that's a part of the five SOLID principles, but it's very much related to the five SOLID principles, and basically it says, if you have abstractions, in this case, if you have interfaces or abstract-based classes, and those abstractions are not being reused by being implemented by various different concrete classes, then you probably have poor abstractions. So before we talk about the Reused Abstractions Principle, it's necessary to understand what is an abstraction actually, and Robert C. Martin defines an abstraction as the elimination of the relevant and the amplification of the essential.

 So instead of designing interfaces up front, start by creating the concrete behavior of the system and then when you've added some concrete behavior, maybe not all of the system, but just some of the system, start looking for features or behaviors that those classes have in common. So you might discover if you start looking for those common behaviors that three classes could implement the same interface, and then you can add that interface and let those three classes implement the same interface, and you might discover that other classes could implement a common interface, and then you could introduce that interface. So the point here is that interfaces are not designed, interfaces are discovered as the system grows, so start with the concrete behavior, and then discover the abstractions as commonality emerges.

The second of the five SOLID principles is the Open Closed Principle, which says that a class should be open for extensibility, but closed for modification. Essentially what this means is that when you've written a class and put the class into production or other clients rely on that class, you are no longer allowed to make changes to that class. Instead, if you want to redefine the behavior of that class it should be open for extensibility, which means that anyone should be able to extend the class in order to redefine parts of its behavior. The only exception to the rule that you're not allowed to make changes to classes that are already being used, is if you discover a bug in that class, so bug fixing is still OK, but otherwise you are not really allowed to make changes to that class once it's being used by other clients, and that sounds a little bit extreme, but the motivation for doing this is that it reduces churn in the sense that once other clients are beginning to rely on a class that you wrote, changing the behavior of such a class would impact all the clients that use this class, and that can have ripple effects further on, because if those clients then need to change, they may have other clients downstream that rely on those, so sometimes doing a simple change in a class that's very essential, will have profound effects on your entire code base

Here's the FileStore class, one of the concrete classes that are part of the sample code for this course, and if you want to make this class closed for modification, but open for extensibility, the way you can open it for extensibility is simply by adding the virtual keyword to each of the members. This is the inheritance-based way of opening this class for extensibility so any other programmer who comes by and wants to change part of the behavior of the FileStore class can override one or more of the members of this class and redefine the behavior, and he or she can call the base implementation if she wants to do that.

 

If we want to use a different logging method we can simply inherit from the StoreLogger base class and override all the methods. 

 

 

We might face an issue while replacing the new logger implementation with as it is newed up in the constructor. This is not an ideal situation since we can use DI but to make the class more extensible but we can add virtual properties  or make the class abstract and override the virtual abstract properties to their corresponding  values to make the class more open for extensibility  and .

Learn Factory Method