Common Type System—Accessibility and Visibility

Visual C# Tutorials

.NET Framework Tutorials

Common Type System Type Systems Intro § Types and Objects § Type Unification Reference, Value Types § Accessibility, Visibility § Nesting Type Members § Subclassing, Polymorphism Styles of Inheritance § Abstract Classes Interfaces § Abstract and Interface? Sealing Types and Methods Runtime Type Checking Namespaces: Organizing Types Special Types Generics § Further Reading §

This Book Reviewed!

© 2006 Wiley Publishing Inc.

Accessibility and Visibility

Before delving into each of the member types available, let’s briefly discuss the visibility and accessibility rules for both types and members. Visibility defines whether a type is exported for use outside of an assembly, the unit of packaging and reuse for managed binaries. Accessibility defines what code inside an assembly can access a type or specific member. In both cases, we can limit what parts of the system can "see" a type or member.

The visibility of types is determined by your compiler and is heavily dependent on accessibility rules. In general, whenever a type uses the public or family accessibility declaration, it becomes visible to other assemblies. All visible types are marked as such in the assembly’s manifest. Although these rules are not precise, they are sufficient for most purposes. We’ll limit further discussion here to accessibility modifiers.

By "see" in the opening paragraph, we just mean that the runtime will enforce that all references to types and members are done in a manner that is consistent with the policy outlined here. This provides safety to ensure that encapsulation of data is maintained and that certain invariants can be controlled by the type itself. Further, the Visual Studio IDE hides such members and the C# compiler checks these access policies at compile time so that developers don’t accidentally make invalid references that fail at runtime.

Whether code has access to a member is partially defined by lexical scoping in your favorite language and partially by the accessibility modifiers on the member itself. Below are the valid accessibility modifiers. Note that many languages, C# included, only support a subset of these:

• Public: The type or member may be accessed by any code, internal or external to the assembly, regardless of type. This is indicated by the public keyword in C#.

• Private: This applies to members (and nested types, a form of member) only. It means that the member may only be accessed by code inside the type on which the member is defined. This is indicated with the private keyword in C#. Most languages use private as the default for members if not explicitly declared.

• Family (Protected): Applies only to members, and means a member may be accessed only by the type on which the member is defined and any subclasses (and their subclasses, and so on). This is indicated by the protected keyword in C#.

• Assembly: Accessible only inside the assembly in which the type or member is implemented. This is often the default for types. This is indicated by the internal keyword in C#.

• Family (Protected) or Assembly: Accessible by the type on which the member lives, its subclass hierarchy, and any code inside the same assembly. That is, those who satisfy the conditions for Family or Assembly access as defined above. This is marked by the protected internal keywords in C#.

• Family (Protected) and Assembly: Accessible only by the type on which the member lives or types in its subclass hierarchy and that are found in the same assembly. That is, those that satisfy the conditions for both Family and Assembly access as defined above. C# does not support this accessibility level.