aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Abstract inner classes Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Abstract inner classes" Watch "Abstract inner classes" New topic
Author

Abstract inner classes

Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
Hi All:
I have with some programs found out that it is possible to declare an inner class abstract. In this case, the outer class need not be declared abstract. However, can someone tell me if there is any situation why someone would want to declare an inner class abstract and how we can define the undefined methods in this inner class? One method is to extend the outerclass and define the abstract methods declared in the abstract inner class. Also, how we can create an instance of the subclass of this inner class assuming that it is no longer abstract?
Any help would be appreciated.
Jim Goodwin
Greenhorn

Joined: Sep 15, 2000
Posts: 14
The hardest part about this is imagining a realistic scenario
where you might need it. One book I read pointed out this
possibility and remarked that it was pretty far-fetched.
Anyway, say you have a class Outer, with an inner class Inner, which is abstract. You can either
(A) add one or more additional inner classes K1, K2, ... to
Outer, which are concrete and extend Inner, and then given
an instance X of Outer, you can do x.new K1(), I believe.
(B) A more realistic scenario is that you have a sort of
lock-and-key arrangement between outer and inner classes,
and you have some logic that can operate on this at the
abstract level, but each concrete implementation uses its
own implementation of lock and a matching implementation of
key.
So you could write a new class WayOuter, which extends Outer, and has inner classes K1, K2, ... etc, which extend Outer.Inner,
and then given an instance w of WayOuter, you can do
w.new K1(), I believe.
Where it gets interesting is that you can write an abstract
method in Outer that says "gimme an instance of my inner
class, whatever the concrete version of it ought to be":
abstract Inner getMyInnards();
and then you can write methods (concrete, with implementations)
in Outer that get the appropriate instance by calling getMyInnards and doing whatever they need to do. Then when you
implement all this in a fully-concrete subclass, like WayOuter, you have to implement
Inner getMyInnards() { return new K1(); }
or whatever the appropriate Kn is, and then the algorithms
implemented at the more abstract level are completed and run.
All this from memory i.e. I haven't checked it or tried it out.
Now if you aren't confused yet, you can go think about how this all works if Inner is static (:-).
Jim
Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
Originally posted by Jim Goodwin:
The hardest part about this is imagining a realistic scenario
where you might need it. One book I read pointed out this
possibility and remarked that it was pretty far-fetched.
Anyway, say you have a class Outer, with an inner class Inner, which is abstract. You can either
(A) add one or more additional inner classes K1, K2, ... to
Outer, which are concrete and extend Inner, and then given
an instance X of Outer, you can do x.new K1(), I believe.
(B) A more realistic scenario is that you have a sort of
lock-and-key arrangement between outer and inner classes,
and you have some logic that can operate on this at the
abstract level, but each concrete implementation uses its
own implementation of lock and a matching implementation of
key.
So you could write a new class WayOuter, which extends Outer, and has inner classes K1, K2, ... etc, which extend Outer.Inner,
and then given an instance w of WayOuter, you can do
w.new K1(), I believe.
Where it gets interesting is that you can write an abstract
method in Outer that says "gimme an instance of my inner
class, whatever the concrete version of it ought to be":
abstract Inner getMyInnards();
and then you can write methods (concrete, with implementations)
in Outer that get the appropriate instance by calling getMyInnards and doing whatever they need to do. Then when you
implement all this in a fully-concrete subclass, like WayOuter, you have to implement
Inner getMyInnards() { return new K1(); }
or whatever the appropriate Kn is, and then the algorithms
implemented at the more abstract level are completed and run.
All this from memory i.e. I haven't checked it or tried it out.
Now if you aren't confused yet, you can go think about how this all works if Inner is static (:-).
Jim

Jim:
Thank you very much for the response. Sorry for the delay in posting this message but I happened to see it only today. Yes, I did check out your suggested methods 1 and 2 to create an instance of inner class and they worked fine.
The abstract inner method was quite interesting. I tried it out and it was neat! But, I wonder if such implementations are practically done!
Haven't tried the static option yet!
Thanks a bunch for your detailed and interesting response. I appreciate that.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Abstract inner classes
 
Similar Threads
about inner classes
Abstract class
Question is ambigitive
abstract method
abstract class