This week's book giveaway is in the Agile and other Processes forum. We're giving away four copies of The Mikado Method and have Ola Ellnestam and Daniel Brolund on-line! See this thread for details.
Right approach for what? What problem are you trying to solve with an abstract nested class? Typically nested class or interface that's meant to be extended or implemented will be static. Unless you have a really good reason to do it the way you are (which is unlikely), I would change it.
deepak carter wrote:just wanted to know whetehr this is the right approach
Almost certainly not. The appropriate situations for using an inner class are fairly limited. I can't think of a single reason to use an abstract inner class.
deepak carter wrote:the code is working fine but just wanted to know whetehr this is the right approach and is there ia another way
I guess that depends on whether you understand why it didn't work in the first place.
Do you know what non-static nested classes are, or why you might need one? (Hint: they're quite rare.)
I'm not trying to put you down, but it seems to me that, if not, you need to do some reading in the Tutorials; otherwise, it's a bit of a waste of time.
Winston
Isn't it funny how there's always time and money enough to do it WRONG?
Are you by any chance confusing "anonymous inner class" with "abstract inner class"?
The reason abstract inner classes would make so little sense, is what would extend them? Only another inner class (as your code demonstrates)! While I suppose it could be done this way, it seems very "un-OOP" in it's in-extensibility and anti-reuse.
Anonymous inner classes, on the other hand, are pretty widely used in java, and are spoken of frequently when discussing java. That's where you implement an interface by writing out only it's required method(s):
OCPJP
In preparing for battle I have always found that plans are useless, but planning is indispensable. -- Dwight D. Eisenhower