Interfaces

 

Appendix A - Principles of Object-Oriented Programming
bySimon Robinsonet al.
Wrox Press 2002

  

Earlier in this appendix, we indicated that there were two types of inheritance: implementation inheritance and interface inheritance. So far we've said a lot about implementation inheritance; in this section we are going to look more closely at interface inheritance.

In general, an interface is a contract that says that a class must implement certain features (usually methods and properties), but which doesn't specify any implementations of those methods and properties. Therefore you don't instantiate an interface; instead a class can declare that it implements one or more interfaces. In C#, as in most languages that support interfaces, this essentially means that the class inherits from the interface.

To get an idea of how an interface looks in programming terms, we'll show the syntax for the definition of an interface that is defined in the .NET base classes, IEnumerator , from the System.Collections namespace. IEnumerator looks like this:

   interface IEnumerator     {     // Properties     object Current {get; }     // Methods     bool MoveNext();     void Reset();     }   

As you can see, the IEnumerator interface has two methods and one property. This interface is important in implementing collections, and is designed to encapsulate the functionality of moving through the items in a collection. MoveNext() moves to the next item, Reset() returns to the first item, while Current retrieves a reference to the current item.

Beyond the lack of method implementations, the main point to note is the lack of any modifiers on the members. Interface members are always public, and cannot be declared as virtual or static.

So why have interfaces? Up to now we've treated classes as having certain members, and not concerned ourselves about grouping any members together our classes have simply contained a list of various miscellaneous methods, fields, properties, and so on. There are often situations in which in order to be able to use a class in a certain way, we need to know that the class implements certain features. An example is provided by the foreach loop in C#. In principle, it is possible to use foreach to iterate through a class instance, provided that that class is able to act as if it is a collection. How can the .NET runtime tell whether a class instance represents a collection? It queries the instance to find out whether it implements the System.Collections.IEnumerable interface. If it does, then the runtime uses the methods on this interface to iterate through the members of the collection. If it doesn't, then foreach will raise an exception.

You might wonder why in this case we don't just see if the class implements the required methods and properties. The answer is that that wouldn't be a very reliable way of checking. For example, you can probably think of all sorts of different reasons why a class might happen to implement a method called MoveNext() , or one called Reset() , which don't have anything to do with collections. If the class declares that it implements the interfaces needed for collections, then you know that it really is a collection.

A second reason for using interfaces is for interoperability with COM. Before .NET came on the scene, COM, and its later versions DCOM and COM+, provided the main way that applications could communicate with each other on the Windows platform, and the particular object model that COM used was heavily dependent on interfaces. Indeed, it was through COM that the concept of an interface first became commonly known. We should stress, however, that C# interfaces are not the same as COM interfaces. COM interfaces have very strict requirements, such as that they must use GUIDs as identifiers, which are not necessarily present in C# interfaces. However, using attributes (a C# feature that we cover in the Chapter 17.

We won't go into any more depth about interfaces here, but we do look more closely at the subject in Chapter 3.