Nesting Interface inside a Class and Nesting Class Inside an Interface

Nesting Interface inside a Class and Nesting Class Inside an Interface
what is the real use of these ? can someone tell me if there are any real use cases in production scenarios where we nest a class inside an interface and vice-versa ?

Can you consider that interface “part of” the class?
Can you consider that class “part of” the interface?
If you can answer yes to either, you have a real‑life use case.
Could you imagine a scenario where you have a(n abstract) Vehicle class with a nested Engine interface? You could have SteamEngine, DieselEngine, ElectricEngine, or PetrolEngine classes.

Of course, you would probably want the Engine interface to be a top‑level type because engines are used in things that are not vehicles.

Swapnil Mishra wrote:Nesting Interface inside a Class and Nesting Class Inside an Interface
what is the real use of these ? can someone tell me if there are any real use cases in production scenarios where we nest a class inside an interface and vice-versa ?

A Map is a collection of name/value pairs. Map.Entry, defines an internal class or interface to contain a pair instance.

Smalltalk defines a generic Pair class, incidentally. I've often lamented that Java does not.

There are certain cases where an internal class was brought out for public use, though I cannot recall specifics. Most of that sort of kinkiness tends to have happened in GUI classes, and some cases have been simplified into stuff like lambdas these days, but for a long time, inner classes and anonymous inner classes were the bane of many a developer's existence.

JavaServer Faces uses a FacesMessage class to define the value and context of messages to be presented on the web page View. FacesMessage has an internal static class that defines the various message severity levels.

Campbell Ritchie wrote:Can you consider that interface “part of” the class?
Can you consider that class “part of” the interface?
If you can answer yes to either, you have a real‑life use case.

This is the traditional way to talk about members of a type.  But I think it's a little off, when talking about nested types.  A better way to look at it is: Is one class or interface only used in conjunction with the other?  That is, does it really only make sense to talk about one when you're using the other?  If so, then one might work as a nested type within the other.  

what is the real use of these ? can someone tell me if there are any real use cases in production scenarios where we nest a class inside an interface and vice-versa ?

 A classic example is Map.Entry in the Java Collections Framework. It's a great way to group types that are logically tied together. By nesting them, you clarify that the inner type is only relevant within the context of the outer one, which keeps the API much cleaner and easier to navigate.

Nice examples by Sir Tim Holloway and Jacka Basej, but apart from this example, I also think this is more of a design choice?

Swapnil Mishra wrote:Nice examples by Sir Tim Holloway and Jacka Basej, but apart from this example, I also think this is more of a design choice?

I suppose.

But isn't everything?

Just curious what approach will we take, if suppose nesting was not allowed? or say nesting would make projects complicated, any alternate cleaner design approach?

Probably we'd just group related classes in a package, rather than nesting them.