When an inner class only makes sense in the context of its outer class, then it is a SecondaryAbstraction.

Example:

  public class Person''''''Query
	{
	public static class Result
	{....}
	public Result doQuery()
	{....}
	}

In this example, the class ''Result'' is only used as the return value from ''doQuery.''  It is a "secondary abstraction," not useful without an instance of ''Person''''''Query'' to create it.

See InnerClass

-----

''I'm not sure I agree with this. What if the outer class is itself only useful within the context of another abstraction? Are they both secondary? A secondary of the secondary? I'm not disputing the concept as much as the usefulness of the wording. Maybe Supporting, Utility, or Subordinate Abstraction might be more direct?''

I share your discomfort with the term.  Someone else created this page, but after many months nobody could say what the heck a secondary abstraction really is.  That bugged me, so I filled in the page with my guess at what the page's original author meant.  I never really got comfortable with the idea, though.  I don't really think about abstractions at all, so "secondary abstractions" are a very big stretch for my very tiny brain.

''Precisely. Any class is an abstraction. An aspect it inherits from the concept. A class is a substantiated concept, but one need not remember it at all times and it makes little sense to make a distinction between primary and secondary abstractions as any class in the inheritance chain is, presumably, rendered useless without its base - why else inherit? Abstractions are unreal rationalization mechanisms. -- Bent Rasmussen''

I prefer to call the thing what it ''is'': "A public static inner class used as the return value for a method."  Then nobody (most especially me) has to guess what I mean.

-----
I believe that private inner classes can ''''hide'''' implementation aspects you don't want to expose outside of a class. Inner classes can directly access fields of the parent class (or the parent instance) and perform other sorts of abuse. Unless this is absolutely needed, it is better to "let your classes be used in ways never predicted by the developer". Maybe you wrote a R'''''esultRenderer class and you'd like to have other places returning Result?
-- TiagoSilveira

Why not just scope your packages appropriately and put the inner class at the package
level?


''Because packages are not proper module abstraction. For example there's no such thing as a sub-package. Also packages can not be instantiated, as modules are instantiated in ML-like languages.m With the new generic features of Java 1.5 the distinction will be even sharper.''

Java isn't ML. Maybe packages are not "proper" in your mind, but they are a way of
structuring dependencies. If you moved the class to the package then they could
have package level access. If only the relevant classes were in the package then
that level of access is excellent. If you dump any old class into a package then it
is not. If a package can be instantiated or not isn't the issue, nor is subpackaging.

''Packages are technically inferior tools for structuring dependencies. Therefore it makes sense to use InnerClass''''''es where they provide '''better encapsulation''' and '''better modularity'''.''
----
CategoryAbstraction