Re: Design Patterns
Arne Vajh=F8j wrote:
A plain nested class does not have access to the local
variables.
If that is not needed then fine.
If that is needed then it has to be either a local
or anonymous class.
Nitpick: or inner class.
And local classes are very rare in the real world.
Sort of. Named local classes are indeed rare. Anonymous local classes
are rather common.
public List<File> getFiles()
{
final FileFilter filter = new FileFilter()
{
@Override boolean accept(File f) { return f.isDirectory(); }
};
// instance of an anonymous local class implementing FileFilter
...
}
This is good Java idiom because the 'FileFilter' instance is GCable when
done. It hasn't got state so its cost is virtually nil. So the local class=
feature gives you good control of a program's memory requirements.
In less educated programmers' code I've seen such implementors scoped at
instance or even (gasp) static member level. And then people wonder at the=
heap requirements.
Java has a funky and nuanced type structure. If you take advantage of
the nuances you get a lot in return.
It helps to use JLS (Java Language Specification) terminology in its
exact, narrowest framing. Really. Some call all nested classes "inner"
classes. Nope. And anonymous classes can be member or local types. It's
all about scope and context.
The JLS has a detailed treatment, and somewhere out there floats a
brilliant infographic going back to 1.2-ish days, but here's a brief
taxonomy.
top level * {public, package},
nested {static, inner {member, local}} * {any access}
This is off the top of my head, so any corrections welcomed.
There's a lovely corner case involving
public class Containing
{
private void doSomething() {...}
public class Within extends Containing
{
// @Override // ?
public void doSomething()
{
Containing.this.doSomething();
// super.doSomething(); // ?
...
}
}
}