Using the Class View to Spy on Structure and Access Modifiers

Choose Class View from the View menu in the IDE. This view will become your best friend as you begin writing your own classes. It shows the classes in the current solution and displays the hierarchy that starts with classes at the highest level of the solution, all the way down to individual elements of the class.

At the top level of the tree is the current project, the one I named WindowsApplication1. Under the Classes hierarchy, you can see a single class, namely Form1. If you expand the Bases And Interfaces node, you'll see the properties and methods that Form1 inherits from the base class. This view also shows the five defined methods of Form1 (Button1_Click, Dispose, Form1_Load, InitializeComponent, and New).

Recall that within a class, methods are implemented by using subroutines and functions, but to the outside world they are methods. Notice that the New method doesn't have a key icon next to it. The absence of a key means that the method is defined with the Public access modifier. Public access means that the method can be used by code from the world outside the class. Having public members makes sense if our class is used in another program. For example, the New method needs to be exposed to the outside world so that an object of the class can be instantiated.

A key icon indicates that the item uses the Protected access modifier. A protected class member is accessible to entities contained in a derived class, provided that the access takes place through the derived class. If you built another class that inherited from a class with a protected member, the derived class would have access to the member.

As I mentioned earlier, an entity using the Friend access modifier is accessible only within the assembly that contains the entity declaration. The Protected Friend modifier unites protected and friend accessibility; in other words, variables of this type are accessible from all code within the same assembly and are also accessible from all derived classes.

Notice that the three fields of the Form1 class—components, iFormCounter, and myform—are declared with the Private access modifier. Private variables or objects are available only to the class, module, or structure in which they are declared. This level of access means that no code outside the Form1 class can access properties or events of the Button1 object. If someone inherits from our form, they cannot get at the code implementing the button. Using the access modifier Private on objects within a class allows you to exercise an object-oriented methodology called encapsulation, which simply means that you hide your objects from the outside world and expose only the methods you want. I'll discuss encapsulation (sometimes referred to as data hiding) again in Chapter 3 when we build our own classes.

For a programmer to add the WindowsApplication1 namespace to a new class and inherit a form of type Form1, our program would have to be compiled and turned into an executable. During this process, the assembly and manifest are built. The programmer using our class would add a reference to the executable file in the Solution Explorer and then simply import the namespace. By doing that, the programmer could instantly create WindowsApplication1 forms. However, because the fields use the Private access modifier, the programmer could not get at those. He or she could access only the public method, New, as indicated by the icons next to the methods in Figure 2-10.

Figure 2-10

The WindowsApplication1 program in Class view.

More About Access Types

The access modifiers, Public, Protected, Friend, Protected Friend, and Private, specify the accessibility of the entity, but accessibility does not change the scope of an entity's name. An object might be seen but not be accessible. If no access modifier is specified, a default access type is used depending on the context. But remember what I said earlier about not relying on the default behavior of the language. It's good practice to add the access modifier that you want and not rely on the one the language gives you. Being consistent in this practice helps reduce bugs. A summary of access modifiers is provided in Table 2-4.

Now that you know about access modifiers, let's see how we would add them to the code in our example. If we make our form private, that reference variable can be seen only in our class. It cannot be accessed from the outside. Data encapsulation such as this ensures that the variable can't be modified by unexpected sources.

Public Class Form1     Inherits System.Windows.Forms.Form     Private myform As Form     Shared iFormCounter As Integer = 0

You aren't restricted in the kind of access you can specify in a declaration that's made in context with a different kind of access. For example, a type declared with private access might contain a type member with public access. You have incredible flexibility in what you can permit the outside world to see.

Table 2-4 Access Modifiers
Modifier	Description
Public	Entities declared with the Public modifier have public access. There are no restrictions on the use of public entities.
Protected	Protected access can be specified only on members of classes. A protected member is accessible to a derived class provided that either the member is not an instance member or the access takes place through an instance of the derived class. Protected access is not a superset of friend access.
Friend	An entity with friend access is accessible only within the program that contains the entity declaration.
Protected Friend	Entities declared with the Protected Friend modifiers have the union of protected and friend access.
Private	A private entity is accessible only within its declaration context, including any nested entities.