4.7 Accessibility in Class ModulesThe notion of accessibility (or scope) in class modules is more involved than it is in standard modules. As far as local variables (block-level and procedure-level) are concerned , there is no difference ” we have block scope and procedure-level scope. However, members of a class module can be assigned one of the following access modifiers:
(For standard modules, only Public , Private , and Friend are allowed.) Actually, we can dispense with the Protected Friend modifier in one statement: Protected Friend is equivalent to Protected or Friend . Put another way, if Protected sets a specific range of accessibility (or inheritance ” see below) and Friend sets a different range, then Protected Friend sets accessibility to the union of those ranges ” if a member falls into either range, it passes the accessibility (or inheritance) criterion. Note that class modules themselves can be declared with any one of the three access modifiers: Public , Private , or Friend ( Protected is not allowed). When a class module declaration specifies one of these access modifiers, this simply restricts all of its members to that level of access, unless a member's access is further restricted by the access modifier on the member declaration itself. For instance, if the class has Friend access, no member can have Public access. (Put another way, the Public access is overridden by the Friend class access.) On the other hand, all four access modifiers apply to members of the class module ” that is, to variable, constant, enum, and procedure declarations within the class module. To avoid confusion in discussing the access modifiers, it helps to separate the issue of accessibility of members from that of inheritance of members. 4.7.1 Member InheritanceLet us first address member inheritance. Suppose that a class named Class1 has a derived class named Class1Derived, as shown in the following: Public Class Class1 Public pub As Integer = 1 Private priv As Integer = 1 Protected p As Integer = 1 Friend f As Integer = 1 Protected Friend pf As Integer = 1 End Class Public Class Class1Derived Inherits Class1 Public Sub test( ) ' Not allowed - private members are not inherited Me.priv = 4 ' Allowed only in derived classes in the same project as base class Me.f = 4 ' Allowed in all derived classes Me.pub = 4 Me.p = 4 Me.fp = 4 End Sub End Class Note that the Me. syntax is optional, and we could write, for instance, simply: pub = 4 p = 4 f = 4 fp = 4 The fact that the code: Me.p = 4 is valid in Class1Derived means that this class has inherited the member p. In other words, an object of class Class1Derived has a member variable named p. The fact that: Me.f fails to work in Class1Derived if Class1Derived is in a different project than Class1 means that such classes do not inherit the member f. Now, the rules of inheritance are:
4.7.2 Member AccessibilityNow we come to member accessibility. Unfortunately, the term accessibility is used quite loosely in most documentation, but to make absolutely clear sense of the issue, we must be specific. Many writers simply refer to a member's accessibility, but this is ambiguous. To illustrate , consider the code: Public Class Class1 Public x As Integer = 1 End Class Public Class Class2 Inherits Class1 End Class Now, it makes sense to ask about the accessibility of the Public member x of Class1 or the (inherited) Public member x of Class2. It does not make sense to ask about the accessibility of the member x alone, without mention of the class involved. Indeed, we say that the Public member x of Class1 is accessible from a class Class3 if the following is legal: Public Class Class3 Public Sub Test( ) Dim c1 As new Class1( ) c1.x = 5 End Sub End Class On the other hand, the Public member x of class Class2 is accessible from Class3 if we can write: Public Class Class3 Public Sub Test( ) Dim c2 As new Class2( ) c2.x = 5 End Sub End Class With this in mind, we can describe the accessibility rules clearly:
|