Abstract inner classes

[Anonymous]

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]

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]

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.