Hi, I want to ask you why we need inner classes and why we use them ?
I know how to use inner classes but I don't know why..
views:
392answers:
6Anonymous inner classes in Java are a way to use the adapter pattern.
interface Bar
{
public void bar();
}
class Foo
{
public void foo()
{
// do something relevant
}
// it happens that foo() defines the same contract (or a compatible one) as
// Bar.bar(); with an anonymous inner class we can adapt Foo to the Bar
// interface
public Bar asBar()
{
// return an instance of an anonymous inner class that implements
// the Bar inteface
return new Bar()
{
public void bar()
{
// from an inner class, we can access the enclosing class methods
// as the "this pointers" are "linked"
foo();
}
};
}
}
In Java, make sure you understand the difference between inner classs and nested class:
an inner class is associated with an instance of its enclosing class and has direct access to that object's methods and fields
C# doesn't have inner classes in sense of Java, only nested classes.
See also this Inner Class Example.
Some inner classes are exposed publicly (eg Map.Entry
in Java) but that is by far the exception rather than the norm.
Inner classes are, basically, an implementation detail.
For example, Swing makes extensive use of inner classes for event listeners. Without them you would end up polluting the global namespace with a bunch of classes you otherwise don't need to see (which may make their purpose harder to determine).
Essentially inner classes are a form of scope. Package access hides classes from outside the package. Private inner classes hide that class from outside that class.
Inner classes in Java are also a substitute for a lack of function pointers or method delegates (which are in C#) or closures. They are the means of passing a function to another function. For example, in the Executor
class you have:
void execute(Runnable r);
so you can pass a method in. In C/C++ that could be achieved with:
void execute(void (*run)());
being a pointer to a function.
I use them to scope, for example, if I have the class ebook and I have ebookPrice, I enclose ebookPrice between the ebook class, as it is related to it and only usable (at least conceptually) inside it.
ebookPrice may inherit from Price which is in a more higher scope, and related to every other class.
(Just my two cents).
Most of the time I use inner classes is because inner classes are the closest thing to the concept of closure available in other languages. This enables creating and working with an object of inner nested scope which has access to variables of its outer scope. This is often useful in creating callbacks (e.g. defining various Listener
s in Swing) among other things.
This piece from wikipedia might help you understand why we need an inner class:
An instance of a normal or top-level class can exist on its own. By contrast, an instance of an inner class cannot be instantiated without being bound to a top-level class.
Let us take the abstract notion of a Car with four wheels. Our wheels have a specific feature that relies on being part of our Car. This notion does not represent the wheels as wheels in a more general form that could be part of vehicle. Instead it represents them as specific to this one. We can model this notion using inner classes as follows:
We have the top-level class Car. Instances of Class Car are composed of four instances of the class Wheel. This particular implementation of Wheel is specific to the car, so the code does not model the general notion of a Wheel which would be better represented as a top-level class. Therefore, it is semantically connected to the class Car and the code of Wheel is in some way coupled to its outer class.
Inner classes provide us with a mechanism to accurately model this connection. We say that our wheel class is Car.Wheel, Car being the top-level class and Wheel being the inner class.
Inner classes therefore allow for the object orientation of certain parts of the program that would otherwise not be encapsulated into a class.
There are languages that take inner classes to quite some different level, like Beta and Newspeak. In these languages the nesting of classes serves as packaging (ie there are no packages).
For a good coverage of this vision, please refer to "How many concepts for modules do we need?" on the object teams blog. See also the work by Gilad Bracha on his blog...