7

There are some different opinions about simple inner classes, so I was wondering if there is a general consensus on what is good, and when to use private inner classes.

Here's an example that I found, and for which I think it's unnecessary to create an inner class. How good/bad practice is this?

private static class InternalCounter {
  int count;

  public InternalTabManager() {
    count = 0;
  }

  public int increment() {
    return count++;
  }
}

Mind you that in this particular case, one instance is kept in the surrounding class to keep track of a count.

Adam Liss
  • 47,594
  • 12
  • 108
  • 150
Steven De Groote
  • 2,187
  • 5
  • 32
  • 52
  • Have you looked at this: http://stackoverflow.com/questions/2284396/java-anonymous-or-not-inner-classes-is-it-good-to-use-them – claesv Mar 30 '12 at 12:30

6 Answers6

11

Yeah, in this case it does seem very unnecessary but if you have a case where there is some significant functionality and you know that no other class will ever need your inner class and it makes no sense to create a class more globally available then do use an inner class.

BenMorel
  • 34,448
  • 50
  • 182
  • 322
Sachin Kainth
  • 45,256
  • 81
  • 201
  • 304
  • 1
    Thanks, I'll accept this answer as after reading through the related question here on SO it confirms that this is a pretty useless case and adds needless complexity – Steven De Groote Mar 30 '12 at 12:44
5

It depends on the context. If this class could've been replaced with only a single static int, then I see no need to create an inner class.

On the other hand, this code would allow the parent class objects to share a reference to mutable int (using java.lang.Integer wouldn't be possible because is immutable).

The general advice/practice/pattern in this case are Keep It Simple and You Ain't Gonna Need it - if you don't need particular behaviour, don't make your code more complex than absolutely necessary.

So, if the question is: "Is it good practice to create an inner class for simple functionality, when it could have been solved in a simpler way" then the answer is NO.

surfen
  • 4,644
  • 3
  • 34
  • 46
1

I've also used inner classes in this way but nowaday I tend more to make those classes package-private.

You get all the benefits of the inner class, while those two classes are much better to maintain (being in two separate files).

Yes, it is still possible that a class in the same package uses the class accidentally but it is VERY unlikely to happen.

helpermethod
  • 59,493
  • 71
  • 188
  • 276
1

When encountered with such situations, we normally ask the developers to question themselves -

  • How stateful is this object going to be? Is this functionality coupled with the containing class?
  • Can this be a stand alone object? (purpose and reason for the existence)
  • Most importantly, is it cleaner?

Listeners, Presenters (UI model) are functional aspects; and deserve separate existence and are rarely modeled as static inner classes

Auditing entries, initialization constructs are non-functional/code-organization aspects; and don't give a definite answer, and IMO it is ok to use static inner classes

A definitive example for using such, would be a state transition model for a small application.

questzen
  • 3,260
  • 18
  • 21
0

When you want to inherit(extends) more than one class in one java class you can use inner class concept.here you can extend one class by outer class and another by inner class.

kundan bora
  • 3,821
  • 2
  • 20
  • 29
0

My rule of thumb is to use static inner classes if within a single class you have refactored to a handful of private methods that each take a similar (or the same) parameters each time. In this case I like to group those parameters together into a single inner class such that I have a type that succicently describes why those parameters are grouped together.

whaley
  • 16,075
  • 10
  • 57
  • 68