Previous section   Next section

Chapter 8. Interfaces

An interface is a contract that guarantees to a client how a class or structure will behave. When a class implements an interface, it tells any potential client "I guarantee I'll support the methods, properties, events, and indexers of the named interface." (See Chapter 5 for information about methods and properties, see Chapter 12 for information about events, and see Chapter 9 for coverage of indexers.)

An interface offers an alternative to a MustInherit class (see Chapter 6) for creating contracts among classes and their clients. These contracts are made manifest using the Interface keyword, which declares a reference type that encapsulates the contract.

Syntactically, an interface is like a class that has only MustInherit methods. A MustInherit class serves as the base class for a family of derived classes, while interfaces are meant to be mixed in with other inheritance trees.

When a class implements an interface, it must implement all the methods of that interface; in effect the class says "I agree to fulfill the contract defined by this interface."

Inheriting from a MustInherit class implements the is-a relationship, introduced in Chapter 4. Implementing an interface defines a different relationship that we've not seen until now: the implements relationship. These two relationships are subtly different. A car is a vehicle, but it might implement the CanBeBoughtWithABigLoan capability (as can a house, for example).

Mix Ins

In Somerville, Massachusetts, there was, at one time, an ice cream parlor where you could have candies and other goodies "mixed in" with your chosen ice cream flavor. This seemed like a good metaphor to some of the object-oriented pioneers from nearby MIT who were working on the fortuitously named SCOOPS programming language. They appropriated the term "mix in" for classes that mixed in additional capabilities. These mix-in or capability classes served much the same role as interfaces do in Visual Basic .NET.

When specifying interfaces, it is easy to get confused about who is responsible for what. There are three concepts to keep clear:

The interface

This is the contract. By convention, interface names begin with a capital I; thus, your interface might have a name like IPrintable. The IPrintable interface might describe a Print( ) method.

The implementing class

This is the class that agrees to the contract described by the interface. For example, Document might be a class that implements the IPrintable interface, and thus provides a Print( ) method.

The client class

This is a class that calls methods from the implementing class. For example, you might have an Editor class that calls the Document class's Print( ) method.

Interfaces are a critical addition to any framework, and they are used extensively throughout .NET. For example, the collection classes (array lists, stacks, and queues) are defined, in large measure, by the interfaces they implement. (The collection classes are explained in detail in Chapter 9.)

In this chapter, you will learn how to create, implement, and use interfaces. You'll learn how one class can implement multiple interfaces. You will also learn how to make new interfaces by combining existing interfaces or by extending (deriving from) an existing interface. Finally, you will learn how to test whether a class has implemented an interface.


  Previous section   Next section
Top