Today I wrote my first meaningful program in Groovy-

It was a small script to extract some information from a XML

It took me the same time to learn Groovy and code this script- the same time it would have taken me to do it in Java.

The brevity of the program was breathtaking. Few lines of code- and I was on the way slurping away the XML.

Another first…

Being an OOP nut- its been ages since I have written a single line of code- outside a class. So today- I broke another barrier.


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.


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


Last night I downloaded and got my first sample program running on grails.

I had been reading about grails for a while- so decided to check on the hype myself

And I was…fairly surprised- pleasantly to see what it had to offer

The time between downloading grails and having it up and running with a small program, not a hello word program – but an actual program which would list and add objects,  was somewhere between 10-15 minutes.

Doing the same thing in Java from scratch would have taken me- well ages.

I know Grails has a strong integration with Spring- so I guess it should be able to deliver lots if not all the advantages that Spring has to offer.

Grails is built on top of Groovy- which is in turn built on top of Java.

I for one do not want to retire Java – just because it has outlived its life and its time for more snappy languages to move in. The romance of somewhat new syntax while still have the familiarity of Java  doesn’t excite me too much

The luxury of not adding semi-colons at the end of line-may excite some people- but it doesn’t tickle me to death that I wont have to worry about any more. Years ago when i would struggled with compilation errors- yes at that time- it would have been a help- but personally its too late for me to benefit from this

The one thing that bothers me is the speed- since Groovy is  built on top of Java- it will be  factor slower than Java. That factor can be reduced but not eliminated.

What remains to see if does the advantages of Groovy outweigh this factor?

© 2011 Technology Cafe Suffusion theme by Sayontan Sinha