Nbsp;   Member Accessibility

When defining a type’s member (which includes nested types), you can specify the member’s acces- sibility. A member’s accessibility indicates which members can be legally accessed from referent code. The CLR defines the set of possible accessibility modifiers, but each programming language chooses the syntax and term it wants developers to use when applying the accessibility to a member. For ex- ample, the CLR uses the term Assembly to indicate that a member is accessible to any code within the same assembly, whereas the C# term for this is internal.

Table 6-1 shows the six accessibility modifiers that can be applied to a member. The rows of the

table are in order from most restrictive (Private) to least restrictive (Public).

TABLE 6-1Member Accessibility

Of course, for any member to be accessible, it must be defined in a type that is visible. For example, if AssemblyA defines an internal type with a public method, code in AssemblyB cannot call the public method because the internal type is not visible to AssemblyB.

When compiling code, the language compiler is responsible for checking that the code is refer- encing types and members correctly. If the code references some type or member incorrectly, the compiler has the responsibility of emitting the appropriate error message. In addition, the just-in-time (JIT) compiler also ensures that references to fields and methods are legal when compiling IL code into native CPU instructions at run time. For example, if the JIT compiler detects code that is improperly attempting to access a private field or method, the JIT compiler throws a FieldAccessException or a MethodAccessException, respectively.

Verifying the IL code ensures that a referenced member’s accessibility is properly honored at run time, even if a language compiler ignored checking the accessibility. Another, more likely, possibility is that the language compiler compiled code that accessed a public member in another type (in an- other assembly); but at run time, a different version of the assembly is loaded, and in this new version, the public member has changed and is now protected or private.

In C#, if you do not explicitly declare a member’s accessibility, the compiler usually (but not always) defaults to selecting private (the most restrictive of them all). The CLR requires that all members of an interface type be public. The C# compiler knows this and forbids the programmer from explicitly speci- fying accessibility on interface members; the compiler just makes all the members public for you.

Furthermore, you’ll notice the CLR offers an accessibility called Family and Assembly. However, C# doesn’t expose this in the language. The C# team felt that this accessibility was for the most part use- less and decided not to incorporate it into the C# language.

When a derived type is overriding a member defined in its base type, the C# compiler requires that

the original member and the overriding member have the same accessibility. That is, if the member in the base class is protected, the overriding member in the derived class must also be protected.

However, this is a C# restriction, not a CLR restriction. When deriving from a base class, the CLR allows a member’s accessibility to become less restrictive but not more restrictive. For example, a class can override a protected method defined in its base class and make the overridden method public (more accessible). However, a class cannot override a protected method defined in its base class and make the overridden method private (less accessible). The reason a class cannot make a base class method more restricted is because a user of the derived class could always cast to the base type and gain access to the base class’s method. If the CLR allowed the derived type’s method to be less acces- sible, it would be making a claim that was not enforceable.

Date: 2016-03-03; view: 652