| Encapsulation and information hiding are object-oriented terms you might have encountered before. They are terms that have to do with strategy. Encapsulation literally means adding membersfields, properties, methods , and eventsto classes or structures. As a general rule, members are added where they are most advantageous; that is, where they will promote the greatest reuse or an optimal refinement of your implementation. A class consumer is a programmer that will create instances of the class. The producer (the person who creates the class) might be the ultimate consumer too. A generalizer is a consumer that will inherit from your class. Information hiding has to do with the partitioning of members between private, protected, public, and friend access to alleviate the burden of consumers or generalizers from learning about all members of your classes or structures. By limiting the number of members that consumers and generalizers have to learn aboutthat is, by selectively hiding informationyour classes will be easier to consume . Access Specifiers The access specifiers Private, Protected, Public, Friend, and Shadows (we'll look at Shadows later in this chapter) are used to support information hiding. Code in a class that you want to make available for general consumption is specified as having Public access. We say that a public interface is made up of Public members. Public members are implemented for the benefit of class consumers. Implement Protected members when you want to hide information from public consumers, but want to facilitate consumption by generalizers. Private members are for internal consumption only. We refer to members with Private access as implementation details. Only the producer needs to be concerned with the implementation details of a class. Finally, Friend and Protected Friend are used to indicate that classes are consumable by entities in the same application. Friend access means intra-application access only. For example, if you define a class library and external consumers don't need or shouldn't have access to some classes in your class library, make those classes Friend classes. As a general rule, make all methods Protected unless they have to be public. Reveal class members judiciously and deliberately. Working with Scope Scope has been extended in Visual Basic .NET to include block scope. New scope rules in Visual Basic .NET were introduced in Chapter 3. In addition to existing and new block-level scope rules, there is another aspect of scope that applies to Visual Basic .NETsupport for inheritance introduces additional scope considerations. When you inherit from an existing class, your new class has all of the inherited Protected, Friend, and Public members in the new class's scope. Fortunately, Visual Basic .NET won't allow you to create name confusion; the compiler will warn you of name conflicts. You can either rename conflicting members to create two disparate entities, or use the Shadows keyword to clarify name conflicts. (Refer to the section on "Using the Shadows Modifier" later in this chapter.) | 
