Inner classes

From ByteWiki

In Object Oriented design, we usualy say that any class that models some concrete concept should get it's own existence. For example, if we built an OO email server, we might have a class to model individual email messages as well as a class to model the server itself. This makes sense because email messages are conceptualy quite seperate from an email server, so we reinforce that seperation in the design.

In this case it also makes sense to do this because we are likely to have many instances of mail message, yet will probably only need a single server instance.

It is also possible to have classes inside other classes (hence the name "inner classes").

In a case where we wish to enforce encapsulation (data hiding), we make an inner class which by default is private to it's outer class. Nobody else can see the inner class.

We often do this with utility classes like the WindowAdapter. Since the WindowAdapter is only relevent to the JFrame it's closing, and since the JFrame is a top level container (which means there is only likely to be a single instance), then it just doesn't make sense to have the WindowAdpter any where other than inside the JFrame.

Alternative to Inner Classes

Inner Classes are often used in java as a mechanism for call backs, particularly in GUI programming. When event X happens, execute the method X in this class. This is necessary to comply with the "everything is an object" approach used by java.

C coders will know that a function pointer is the simplest form of call back. You pass in a pointer and when the even happens, the code (function) at that address is executed. This does not require any structure to work so it is flexible, but you have to pass any data explicitly which requires careful design to make it future proof (a good design is to allow a void pointer which can be typecast to a custom struct, but without rtti this can lead to problems as well).

A feature of Object Pascal (as used by Delphi) is to use method pointers. These are like function pointers, and a class pointer rolled into one. It allows you to create an object and say when event X happens, call this method on this class (which may well be self). This gives a strongly typed and rtti compatible way of handling call backs. You still get all the features of OO such as inheritance and hiding but the flexibility of call back functions.

Which way is best? I like the Delphi way. It is especially good for OO based GUIs and I think it is the key which makes Delphi so good for building GUIs.

What about C#? C# has delegate. A delegate is define like a method signature. You then create a new delegate object of the method you want to call (which has the signature of the delegate) and you can pass that around. These are used heavily in conjuction with events. Delegates can be added to events and an event can have many delegates. executing the event then goes and calls all (one or none) of the delegates that have been added to that event. This is conceptually very similar to creating objects in Java to handle call backs. You get the type safty but it is all done in much cleaner code.

// define delegate
public delegate void StringDelegate(string s);
// create instance of delegate
StringDelegate Writer = new StringDelegate(object.MethodName);
// Calling the delegate
Writer("String passed to Writer\n"); 

There is the potential that under the hood, c# and Delphi act in similar fashion since they both had the same man driving them: http://en.wikipedia.org/wiki/Anders_Hejlsberg