> could anyone tell why an interface can be nested
> within another interface. Where is it used? Is it
> used by any design patterns... ?
This is so you can apply the important locality design principle. For variables it means that you should declare variables as close as possible to where they're going to be used. When it comes to types (both classes and interfaces are types), it means that they should be defined as local as possible too. That's why there are inner classes and interfaces.
Not many know this but you can actually declare a class within a method. This makes sense if you're going to use it only there.
So taking the Entry interface in Map Interface as example... inner interfaces are used to provide for added functionality to an implementaion through an interface. eg A hashMap implements Map gives you an an additional interface Entry that enables you to view the map in another way... am i right.
ok I kind of get an idea
> What makes you think not many people know this?
Well I for one didn't know... but I am not many people
thnks for the replies
> > Not many know this but you can actually declare a
> > class within a method. This makes sense if you're
> > going to use it only there.
>
> What makes you think not many people know this?
Your reply. Only little known features draw out responses like yours.
> So taking the Entry interface in Map Interface as
> example... inner interfaces are used to provide for
> added functionality to an implementaion through an
> interface. eg A hashMap implements Map gives you an
> an additional interface Entry that enables you to
> view the map in another way... am i right.
Map is a type. Entry is a type too. Entry is defined as being "inside" Map because it naturally belongs there. It's a design decision. When you see a variable declaration like,
Map.Entry e;
You know e doesn't hold just any Entry object. It's holds an Entry object of a Map.
Both Map and Entry are interfaces. It's also a design decision. Any of them could have been a class but interfaces give more flexibility to a design.
> do u know
> of anydesign patterns that use innner interface ...
Many, maybe most, desing patterns CAN make use of nested classes/interfaces. Here's an implementation of the Builder pattern using inner interfaces (listing on page 2).
http://www.javaworld.com/javaworld/jw-01-2004/jw-0102-toolbox.html
> > Not many know this but you can actually declare a
> > class within a method. This makes sense if you're
> > going to use it only there.
>
> What makes you think not many people know this?
I'd agree with UJ's logic for one. There are not many people on this globe who know Java, so there would not be many who know about this. ;)
> I'd agree with UJ's logic for one. There are not many
> people on this globe who know Java, so there would
> not be many who know about this. ;)
haha, that's a different way of looking at it. UJ's made it pretty obvious they meant it as a jab at the community by their response.
> > I'd agree with UJ's logic for one. There are not many
> > people on this globe who know Java, so there would
> > not be many who know about this. ;)
>
> haha, that's a different way of looking at it. UJ's
> made it pretty obvious they meant it as a jab at the
> community by their response.
I think you should rest for a while. You still seem groggy from that left-hook I gave you. -:)
Anyway I think this is one of the least known features of Java.
void m() {
class X { // class local to a method
}
X x = new X();
}
My "logic" is based on the general observation that core features are better known than peripheral ones. That's why I can state with some confidence that the if-statement is known to more Java programmers than local inner classes. Further more, in my estimation, local inner classes is so esotheric that it should be one of the very last features someone encounters before graduating as guru with a black belt in Java.
But you disagree of course. Local inner classes was the first Java feature you learned about so why shouldn't that apply to everybody else. -:)
I learned about local classes long before I learned generics were not covariant. However, I don't think I'd go around making comments that "Most people don't know a List<Integer> is not a List<String>" so your logic doesn't really fly with me. The fact that you tried to insult me rather than answering the question showed exactly why you made the comment.