Nested Types
A nested type is a type that is a member of some other type. Nested types should be tightly coupled to their declaring type and must not be useful as a general purpose type. Nested types are confusing to some developers and should not be publicly visible unless there is a compelling reason to do so. In a well-designed library, developers should rarely have to use nested types to instantiate objects or declare variables.
Nested types are useful when the declaring type uses and creates instances of the nested type, and use of the nested type is not exposed in public members.
Do use nested types when the relationship between the nested type and its outer type is such that member accessibility semantics are desirable.
Because a nested type is treated as a member of the declaring type, the nested type has access to all other members in the declaring type.
Do not use public nested types as a logical grouping construct; use namespaces for this.
Avoid publicly exposed nested types. The only exception to this is when variables of the nested type need to be declared in rare scenarios such as subclassing or other advanced customization scenarios.
Do not use nested types if the type is likely to be referenced outside of the declaring type.
Declaration of variables and object instantiation for nested types should not be required in common scenarios. For example, an event-handler delegate that handles an event defined on a class should not be nested in the class.
Do not use nested types if they need to be instantiated by client code. If a type has a public constructor, it should probably not be nested.
Ideally, a nested type is instantiated and used only by its declaring type. If a nested type has a public constructor, this would indicate that the type has some use separate from its declaring type. In general, a nested type should not perform tasks for types other than its declaring type. If a type has a wider purpose, it most likely should not be nested.
Do not define a nested type as a member of an interface. Many languages do not support such a construct.
Portions Copyright 2005 Microsoft Corporation. All rights reserved.
Portions Copyright Addison-Wesley Corporation. All rights reserved.
For more information on design guidelines, see the "Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries" book by Krzysztof Cwalina and Brad Abrams, published by Addison-Wesley, 2005.
See Also
Concepts
Other Resources
Type Design Guidelines
Design Guidelines for Developing Class Libraries