When designing classes for outside use (eg. API) or as a library component for multiple applications, readability and easy element (field/function) selection is important. No developer likes hunting around for fields or functions; a legible and hierarchical organization of elements aids quicker turnaround time in code delivery.
In some cases, a large class is needed that can possibly contain dozens or hundreds of elements. Naming convention can aid in this organization (ie. using common prefixes in field/function names) but are not inherent to the grammar of languages. Therefore, no semantic advantage can be taken from using these conventions.
class Store
ItemList clothingMensShirts
ItemList clothingMensShoes
...
ItemList clothingWomensShirts
ItemList clothingWomensShoes
...
ItemList hardwareToolsWrenches
...
ItemList hardwareMaterialsWood
...
ItemList electronicsGamesPCFallout3Copies
...
ItemList electronicsAudioHeadphones
...
The current solution to the management of large classes is by using publicly exposed nested classes.
class Clothing inherits Department
ClothingSection mens
...
class Mens inherits ClothingSection
ItemList shirt
ItemList shoes
...
abstract class Store
...
Department clothing
...
class IKEA inherits Store
...
IKEA newYorkStore = new IKEA();
newYorkStore.buy(newYorkStore.clothing.mens.shirts[0]);
This is a possible solution but also comes with it's own problems. Encapsulation of the nested class will not only hide information from the public user but also from the parent class as well. This can be problematic when designing an abstract class where the functions, that must be implemented, must also access non-public elements inside the nested. For example, in the store example, any data the top level class (Store) may want to access from the lower level ones (ClothingSection, ItemList) will be unavailable if that data must also be hidden from the public user.
Also, the nested classes cannot be abstracted to require implementation from any inheriting class. Revisting the store example, this means that abstracting the ClothingSection class would require two new classes for one implementation. Creating not only a child Store but also a child ClothingSection class.
Nested classes are helpful for creating logical hierarchies within a class or providing abstract functionality privately inside the class. Although, I would propose the use of namespacing inside a class instead. It would provide the logical hierarchy needed in a very simple way and allow for information sharing across the entire domain of the class. It would need a separate keyword though to prevent use outside of classes.
class Store
classnamespace clothing
classnamespace mens
ItemList shirts
ItemList shoes
...
...
classnamespace womens
ItemList shirts
ItemList shoes
...
...
classnamespace hardware
classnamespace tools
ItemList wrenches
...
...
classnamespace materials
ItenList Wood
...
...
...
