Chapter 13. Interfaces

There are times when you may not want to create a new type, but you do want to describe a set of behaviors that any number of types might implement. For example, you might want to describe what it means to be storable (capable of being written to disk) or printable .

Such a description is called an interface . An interface is a contract. When you design an interface, you're saying "if you want to provide this capability, you must implement these methods , provide these properties and indexers, and support these events." The implementer of the interface agrees to the contract and implements the required elements.

See Chapter 8 for information about methods and properties, Chapter 17 for information about events, and Chapter 14 for coverage of indexers.

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, so your interface might have a name such as IPrintable . The IPrintable interface might require, among other things, a Print( ) method. This states that any class that wants to implement IPrintable must implement a Print( ) method, but it does not specify how that method works. That is up to the designer of the implementing class.

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 IPrintable and thus implements the Print( ) method in whatever way the designer of the Document class thinks is appropriate.

The client class

The client calls methods on the implementing class. For example, you might have an Editor class that has a collection of IPrintable objects (every object in the class is an instance of a type that implements IPrintable ). The client can expect to be able to call Print( ) on each, and while each may implement the method differently, each will do so appropriately and without complaint.

Interfaces Versus Abstract Base Classes

Programmers learning C# often ask about the difference between an interface and an abstract base class. The key difference is that an abstract base class serves as the base class for a family of derived classes, while an interface is meant to be mixed in with other inheritance trees. That is, a class can only inherit from a single parent class, but it can implement multiple interfaces .

Inheriting from an abstract class implements the is-a relationship, introduced in Chapter 6. Implementing an interface defines a different relationship, one you'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).

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

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