• Post Reply Bookmark Topic Watch Topic
  • New Topic

Static inner classes vs Normal (outer?) classes  RSS feed

 
Andy Josh
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've been wondering for a while what the difference between a static inner class and a normal class is. For example:
OuterClass.java


FakeInnerClass.java


Why would I ever want to use InnerClass if I can use FakeInnerClass? I know InnerClass will have access to private static fields of OuterClass, but apparently that is just compiler magic that could be achieved by making accessors. Is it just for ease of use, or is there some other reason to use a static inner class?
 
Campbell Ritchie
Marshal
Posts: 56223
171
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome tot he Ranch

Have you seen the Java™ Tutorials section about nested classes? The idea is that a nested class has an intimate relationship with its enclosing type. Consider an object of a nested class as part of the structure represented by its outer class. This is particularly obvious if you have something like a linked list with a Node inner class. You can make the Node class private if you prefer.
 
Winston Gutkowski
Bartender
Posts: 10574
65
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Andy Josh wrote:I've been wondering for a while what the difference between a static inner class and a normal class is.

Very little, except for what you've obviously discovered.

Why would I ever want to use InnerClass if I can use FakeInnerClass?

Basically: what Campbell said.

There's also an advantage to that proximity in that you generally don't have to repeat as much - for example, documentation.

Personally, I also rather like the structured names that result: Map.Entry makes much more sense to me than MapEntry - or it would if Entry was actually defined in Map.

And that brings up another point: You can define static classes in an interface - and TBH, I don't know why it isn't done more often:makes much more sense to me than having a separate AbstractList class.

But maybe it's just me.

Winston
 
Campbell Ritchie
Marshal
Posts: 56223
171
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Winston Gutkowski wrote:. . . I don't know why it isn't done more often . . .
It is over twenty years since Java® was first designed. A lot has changed in those twenty years. Were static nested classes permitted in interfaces before Java8? I don't know.
 
Winston Gutkowski
Bartender
Posts: 10574
65
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:Were static nested classes permitted in interfaces before Java8? I don't know.

At least since 6; but earlier...? Dunno.

Winston
 
Campbell Ritchie
Marshal
Posts: 56223
171
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If they were there is Java6 they will have been there since inner classes were first invented.
 
Andy Josh
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks! I realize my question didn't clarify what I was looking for. You guys still answered my desired question, but I was concerned about whether there were memory/performance implications to using one over the other. It appears from the responses that there are not. Awesome- now I can use either one as I see fit! ;)
 
Winston Gutkowski
Bartender
Posts: 10574
65
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Andy Josh wrote:You guys still answered my desired question, but I was concerned about whether there were memory/performance implications to using one over the other. It appears from the responses that there are not. Awesome- now I can use either one as I see fit! ;)

In general, performance really shouldn't be an overriding consideration when choosing an implementation. Pick the one that makes most sense, and then maybe consider another if, and ONLY if:
(a) It clearly doesn't perform adequately.
(b) You know (and, more importantly, can prove) that an alternative one will.

HIH

Winston
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!