Geek Answers Handbook

Is it good practice to create an inner class for simple functionality?

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

Here is an example that I found, and for which, I think, there is no need to create an inner class. How good / bad is the practice?

private static class InternalCounter { int count; public InternalTabManager() { count = 0; } public int increment() { return count++; } }

Keep in mind that in this particular case, one instance is stored in the surrounding class to track the account.

+7
source share
6 answers

Yes, in this case it seems very unnecessary, but if you have a case where there is some significant functionality, and you know that no other class will ever be needed by your inner class, and it makes no sense to create a globally accessible class then use the inner class.

+8
source

It depends on the context. If this class could be replaced with only one static int, then I do not see the need to create an inner class.

On the other hand, this code will allow the parent objects of the class to exchange a reference to mutable int (using java.lang.Integer would be impossible because it is immutable).

The general advice / practice / template in this case is Keep It Simple, and you won’t need it - if you don’t do this, you need certain behavior, do not make the code more complicated than it is absolutely necessary.

So, if the question: “It’s good practice to create an inner class for simple functionality, when it could be resolved in a simpler way,” then the answer will be NO .. p>

+5
source

When we encounter such situations, we usually ask developers to ask questions -

  • What will this object look like? Is this functionality related to the containing class?
  • Could this be an independent object? (purpose and reason for existence)
  • Most importantly, is it cleaner?

Listeners, speakers (user interface model) are functional aspects; and deserve a separate existence and are rarely modeled as static inner classes

Audit records, initialization constructs are non-functional / code aspects; and don't give a definite answer, and IMO it's ok to use static inner classes

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

+1
source

If you want to inherit (extend) more than one class in one Java class, you can use the internal concept of the class. Here you can extend one class with an outer class, and the other with an inner class.

0
source

My rule is to use static inner classes if within the same class that you reorganized into several private methods, each of which takes the same (or the same) parameters every time. In this case, I like to group these parameters together into one inner class, so I have a type that succinctly describes why these parameters are grouped together.

0
source

I also used inner classes this way, but now I'm more inclined to have these classes private.

You get all the benefits of an inner class, while these two classes are much better maintained (being in two separate files).

Yes, it is still possible that a class in one package accidentally uses the class, but this is very unlikely.

0
source

More articles:


All Articles