This chapter is from the book
This chapter is from the book
This chapter is from the book
Accessibility
Members of a type can have different accessibility levels. Accessibility levels define which other types can access the members of a type. In many situations, it is desirable to limit the accessibility of a member. If one member implements some functionality for a type, such as data validation of field values, then it may be useful to all other members of that type but may be considered an implementation detail of the type. Developers can limit the accessibility of the member so as to prevent clients from using it. This practice helps to localize the effects of change. For example, if the signature of such a privately scoped member changes, then the change will not affect any of the clients of this type. Thus the effect of the change remains limited to this type's definition. Conversely, accessibility may be restricted to a higher level than private but less than public. This choice could, for example, widen the effect of a change, possibly to the type's assembly, but keep it a much smaller effect than changing a publicly available member.
The CLR supports a number of accessibility levels:
Public: available to all types
Assembly: available to all types within this assembly
Family: available in the type's definition and all of its subtypes
Family or Assembly: available to types that qualify as either Family or Assembly
Family and Assembly: available to types that qualify as both Family and Assembly
Compiler-controlled: available to types within a single translation unit
Private: available only in the type's definition
All members in an interface are public. Types are permitted to widen accessibility. That is, a subtype may make a member more visible, as sometimes occurs with inherited virtual methods, for example. This approach ensures that the method is at least equally visible in the subtype. Use of this widening facility, although legal, is considered problematic at best and should be avoided.