On Wed, 2006-01-04 at 18:09 +0100, Thomas Dudziak wrote: > On 1/4/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > > > Anyone else, just out of curiosity, is there a "best practice" around > > this? My feeling is that if I'm configuring an object that is only used > > by a given class, i.e., Class foo has a collection of Class bar's that > > will be created via Digester, and nothing outside foo uses bar, and then > > making bar an inner class makes it a bit more obvious to me what its > > purpose is and how it fits into the object schema, so to speak... although > > one could argue that it represents coupling and therefore is bad... any > > thoughts? > > You should use inner classes (non-static) only if they have a real > tight coupling to the outer class, i.e. if they always need a outside > instance (think: almost every method of the inner class would > otherwise need an object of the outer class as parameter). > Whether you prefer nested (static) classes or normal classes in the > same package might depend on whether the nested class needs access to > internals of the outer class (private methods) though one could argue > that this is not a good design. > > Other than that it is probably a matter of personal style. But I tend > to avoid static classes for the sole reason that they make the class > bigger and less readable.
Non-static inner classes are of course very useful as "adapters" which implement some interface and map it onto methods of the enclosing class. I generally find them nicer than anonymous classes, though anonymous classes are appropriate in some cases. I agree with you both on all the other points. Cheers, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
