This is one of the most powerful principle of OOP.
The Principle
Simply stated- what this means is- once you are done coding an entity - e.g Class,function etc- you should have no reason to modify it again (…hence closed), but that entity should be available for modification via extensions e.g inheritance or any other smart mechanism you can think on (…hence open)
The only exception - when you would ‘open’ the class for changes is- to fix defects. That’s it
And why do we have this principle?
The rationale behind this s pretty simple. If you don’t touch it you can’t break it. It gives you a better and a solid design- which is resilient to changes and is yet adaptive to ever evolving nature of software
In extreme
The principle in extreme would mean- that once you are done with the class- you will never- ever again modify it (unless of course -you find a defect) - What that would mean is - any new method taht you would like to add should go to a different class- because any such change is not a bug-fix and hence is not a change to be made to this class
Hmmm…Sounds a bit extreme to me
I went and took a look at API for java.lang.String
So if Java team has been following this principle- they wouldn’t have added any new method to this class. Any new feature they would want to provide to this class- they would conjure some other mechanism .
Well- they didn’t do that . I found at least 4 new methods added in 1.5.
If you think about it- even though you have technically open the class for modification- you haven’t increased the chance of any new defects getting reported for the existing methods- though yes- as a whole- this class has become more prone to defects- just because it has newer methods added to it
So what really is a problem?
Software are ever evolving. New features are continuously being added, defects fixed, underlying technologies change.
The question is- how adaptive is your software to all this.
Consider a railway booking system. When it was first launched - the only way to book a ticket was via a terminal at the booking office. Later on - support for online booking is added. Now how does your booking engine adapt to this change? Do you go and start changing code all over to accommodate request coming in from a new medium or do you simply plug in new medium to the existing system ?
One good rule of thumb is
Whenever you see code using if- then-else statements or switch statements- you ‘could’ have stumbled upon a violation of this principle (This is not to mean that any usage of these constructs is a violation !!!)
Related Design patterns
Many design patterns help you confirm to this principle. Decorator, Strategy, Chain of Responsibility.
Caveat
Like I said before- all classes cannot be coded to confirm to the Open Closed principle. You have to pick and choose where would you like to apply these principles. Adding this principles adds complexity- You will want to add to those corner spots which are subject to extensions.
The credits
Dr Meyer- read more about him at wikipedia
http://en.wikipedia.org/wiki/Open/closed_principle
Recent Comments