Just off the top of my head, I would say that method local inner classes tend to be less simple than .... some other options. Can you find a simpler way to accomplish your goal?
JavaBeginnersFaq "Yesterday is history, tomorrow is a mystery, and today is a gift; that's why they call it the present." Eleanor Roosevelt
Joined: Jul 08, 2008
Ok, for some background, but hopefully without giving too much away...
I'm on SortNames (OOP3). I need to declare a class that implements a certain other class so that I can do a sort. I initially declared the class as its own outer class, but was told it would be better as an inner class (I'm not sure why).
So, thinking I should declare the class right before it is used, I declared it within my main method before it is instantiated and I do the sort. I was then told that, as a general rule, it's not a good idea to declare a class within a method.
So now, the only option I can see left is to declare the inner class as a "member" of the outer class. But then to instantiate the inner class I would have to instantiate the outer class, and I'm struggling to see how that would be a better approach?
Hope this all makes sense!
Marilyn de Queiroz
Joined: Jul 22, 2000
Can you can think of a way to declare the new class as a "member" of the outer class without needing to instantiate it in order to use it?
Joined: Jul 08, 2008
You mean declare it as static? But I need an instance of the inner class in order to do the sort. At least I think I do...
http://www.javaranch.com/campfire/StoryInner.jsp wrote:A top-level nested class is little more than another way to control namespace.
True, and therefore they are mostly unwanted since packages give us this control.
I think the point is missed in explaining how it's done and not why. That campfire article does a good job of explaining some pros and cons of inner classes, but it really only brings up "top-level nested classes" (i.e. "static inner classes") to say that "inner classes aren't these" (I'm not suggesting that it should elaborate any more than it already does).
Mark Gandy wrote:I initially declared the class as its own outer class, but was told it would be better as an inner class (I'm not sure why).
Not much point in doing it if you don't know why.
I'm a beginner, but the only time I've ever used a static inner class is when it was also private. For example:
It says "rubbish to reuse; I'm information hiding," and it's probably not a very good technique. In other words, I've used static inner classes for encapsulation, and I propose that's a potential use in addition to controlling namespace. I welcome correction.
In your case, I suspect a static inner class is being recommended for namespace control. If the class in question is called something generic like "Sorter", it's possible that it already exists in your package. In that case, a static inner class might be preferable to creating a new package (but it also might indicate that your package hierarchy isn't robust enough).