What Interfaces Are

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.

Tip

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:

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 internally. 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 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.

ora: 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, and an interface is meant to be mixed in with other inheritance chains. That is, a class can inherit from only a single parent class, but it can implement multiple interfaces.

In addition, when you derive from an abstract class, you must override all the abstract methods in the abstract base class, but you don’t have to override any nonabstract methods. You can simply use the implementation that the base class provides. This is called partial implementation, and it’s very common with abstract classes. Interfaces don’t have any implementation, so you must implement every method defined in the interface. You can’t partially implement an interface.

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).

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.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset