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.
You saw methods and properties in Chapter 8. We’ll discuss indexers in Chapter 14 and events in Chapter 17. We promise you don’t need to know about them for this chapter.
When you specify interfaces, it is easy to get confused about who is responsible for what. There are three concepts to keep clear:
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 internally. That is up to the designer of 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 calls methods on the implementing class. For example, you might have an Editor
class that has an array of IPrintable
objects (every object in the class is an instance of a type that implements IPrintable
, even if they aren’t all the same type). The client can expect to be able to call Print( )
on each object, and although each individual object may implement the method differently, each will do so appropriately and without complaint.
One critical thing to remember about interfaces is that an interface is not a class, and you can’t instantiate an instance of an interface. For example, this won’t work:
IPrintable myPrintable = new IPrintable( );
Interfaces aren’t classes, so they don’t have constructors, and you can’t have an instance of an interface. However—and this is where it gets a bit confusing—if you have a class that implements the interface, you can create a reference to an object of that class, of the type of the interface. Confused? Look at an example. Suppose you have a Document
class that you know implements IPrintable
. Although you can’t create an IPrintable
object, you can do this:
IPrintable myPrintable = new Document( );
myPrintable
is called a reference, which in this case refers to some (unnamed) Document
object. All your code needs to know about myPrintable
is that it refers to some object that implements the IPrintable
interface—it could be a Document
, it could be a Memo
, it could be a GreatAmericanNovel
. Doesn’t matter. This lets you treat interface references polymorphically, just like you can use inheritance to treat objects polymorphically (see Chapter 11 for a refresher, if you need it). You’ll see how this works a little later in the chapter.
Interfaces are a critical addition to any framework, and they are used extensively throughout .NET. For example, the collection classes (stacks, queues, and dictionaries, which we’ll cover in detail in Chapter 14) are defined, in large measure, by the interfaces they implement.