The Common Type System
The Common Type System specifies the types supported by the CLR. The types specified by the CLR include:
ClassesThe definition of what will become an object; includes properties, methods, and events
InterfacesThe definition of the functionality a class can implement, but does not contain any implementation code
Value typesUser-defined data types that are passed by value
DelegatesSimilar to function pointers in C++; often used for event handling and callbacks
The type system sets out the rules that language compilers must follow to produce code that is cross-languagecompatible. By following the type system, vendors can produce code that is guaranteed to work with code from other languages and other compilers because all languages are consistent in their use of types.
Classes
Most Visual Basic developers are familiar with classes. Classes are definitions or blueprints of objects that will be created at runtime. Classes define the properties, methods, fields, and events of objects. If the term fields is new to you, it simply means public variables exposed by the class; fields are the "lazy way" to do properties. Together, properties, methods, fields, and events are generically called members of the class.
If a class has one or more methods that do not contain any implementation, the class is said to be abstract. In VB.NET, you cannot instantiate abstract classes directly; instead, you must inherit from them. In VB6, it was possible to create a class that was just method definitions and then to use the Implements keyword to inherit the interface. You could actually instantiate the interface in VB6, but because it did not have any implementation code, there was no point in doing so.
In VB.NET, you can create a class that has implementation code instead of just the interface, and then mark the class as abstract. Now, other classes can inherit from that abstract class and use the implementation in it or override the implementation as needed. These are new concepts to VB developers. In the past, VB had only interface inheritance, but VB.NET has "real" inheritance, known as implementation inheritance.
In VB.NET, interfaces are separate from classes. In VB6, you created interfaces by creating classes with method definitions but no implementation code inside those methods. You will see more on interfaces in the next section, but realize that although a VB.NET class can implement any number of interfaces, it can inherit from only one base class. This will be examined in more detail throughout the book.
Classes have a number of possible characteristics that can be set and that are stored in the metadata. In addition, members can have characteristics. These characteristics include such items as whether or not the class or member is inheritable.
Interfaces
Interfaces in VB.NET are like the interfaces in previous versions of VB: They are definitions of a class without the actual implementation. Because there is no implementation code, you cannot instantiate an interface but must instead implement it in a class.
There is one exception to the "no implementation code in an interface" rule: In VB.NET, you can define what are called static members. These can have implementation code.
Value Types
In .NET languages, a standard variable type, such as an integer, is native to the language, and it is passed by value when used as an argument. Objects, on the other hand, are always passed by reference. However, a value type is a user-defined type that acts much like an object but is passed by value. In reality, value types are stored as primitive data types, but they can contain fields, properties, events, and both static and nonstatic methods. Value types do not carry the overhead of an object that is being held in memory.
If this seems confusing, think about enums. Enumerations are a special type of value type. An enum simply has a name and a set of fields that define values for a primitive data type. Enums, however, cannot have their own properties, events, or methods.
Delegates
Delegates are a construct that can be declared in a client. The delegate actually points to a method on a particular object. Which method it points to on which object can be set when the instance of the delegate is created at declaration. This allows you to define calls to various methods in different objects based on logic in your code.
Delegates are most often used to handle events. Using delegates, you can pass events to a centralized event handler. Due to the small size of this book, delegates will not be examined later.