Classes: Blueprints for Objects
Classes are symbolic representations of objects; classes describe the properties, fields, methods, and events that form objects in the same way that blueprints describe the items that form buildings. Just as a blueprint can be used to create multiple buildings, a single class can be used to create as many objects as necessary. Just as a blueprint defines which parts of a building are accessible to people who use the building, so too can classes control user access to object items through encapsulation.
Classes and Objects
The terms class and object are sometimes used interchangeably, but in fact, classes describe the structure of objects, while objects are usable instances of classes. Each instance is an exact yet distinct copy of its class. Because an object is an instance of a class, the act of creating an object is called instantiation.
Using the blueprint analogy, a class is a blueprint, and an object is a building made from that blueprint. Usually, changing the data in one object does not change the data in any other object. (The exception is shared members, class members declared with the Shared modifier, which exist independently of specific instances of a class.)
Encapsulation
Encapsulation is the ability to contain and control access to a group of associated items. Classes provide one of the most common ways to encapsulate items. In the example below, the BankAccount class encapsulates the methods, fields, and properties that describe a bank account.
Without encapsulation, you would declare separate procedures and variables to store and manage information for the bank account, and it would be difficult for you to work with more than one bank account at a time. With encapsulation you can use the data and procedures in the BankAccount class as a unit. You can work with multiple bank accounts at the same time without confusion because each account is represented by a unique instance of the class.
Encapsulation also allows you to control how the data and procedures are used. You can use access modifiers, such as Private or Protected, to prevent outside procedures from executing class methods or reading and modifying data in properties and fields. You should declare internal details of a class as Private to prevent them from being used outside of your class; this technique is called data hiding, and is how customer information such as the account balance is protected.
One basic rule of encapsulation is that class data should be modified or retrieved only via Property procedures or methods. Hiding the implementation details of your classes prevents classes from being used in undesired ways, and lets you to later modify such items without risk of compatibility problems. For example, later versions of the BankAccount class could change the data type of the AccountBalance field without breaking other applications that rely on this field having a specific data type.
Inheritance
Like Visual Basic structures, you can use classes to define data types that encapsulate a group of related items. Unlike structures, however, Visual Basic classes can inherit and extend the characteristics of other classes. Classes that serve as a basis for new classes are called base classes. Classes derived from base classes are called derived classes. Derived classes inherit all the fields, properties, methods, and events of the base class. This means you can develop and debug a class once, and then reuse it as the basis for other classes.
The following example defines a base class that represents a generic bank account, and a specific class that inherits the properties of the base class but is customized to describe a checking account.
Class BankAccount
Private AccountNumber As String
Private AccountBalance As Decimal
Private HoldOnAccount As Boolean = False
Public Sub PostInterest()
' Add code to calculate the interest for this account.
End Sub
ReadOnly Property Balance() As Decimal
Get
' Return the available balance.
Return AccountBalance
End Get
End Property
End Class
Class CheckingAccount
Inherits BankAccount
Sub ProcessCheck()
' Add code to process a check drawn on this account.
End Sub
End Class
For more information about inheritance, see Inheritance Basics.
Shared Members
By default, class data is specific to each instance of the class, but there may be occasions when you want a single data item to be shared among all objects created from a class. In such cases, use the Shared modifier to cause a variable to share the same value in all instances of a class (Shared members are sometimes referred to as "static members" in other programming languages). You can call shared methods directly using a class name without first creating an instance of the class.
For more information about shared members, see Shared Members in Visual Basic.
Shadowing
Derived classes can use the Shadows keyword to declare a member with the same name as an inherited member. Shadowed members do not need to be the same data type as the member being shadowed. For example, a property can shadow a variable of type Integer.
For more information about shared members, see Shadowing in Visual Basic.
See Also
Reference
Concepts
Structures and Classes
Inheritance Basics
Shared Members in Visual Basic
Shadowing in Visual Basic