Common Type System—Interfaces

Visual C# Tutorials

.NET Framework Tutorials

Common Type System Type Systems Intro § Types and Objects § Type Unification § Reference, Value Types § Accessibility, Visibility § Type Members § Fields § Methods § Locals Overloading Argument Passing Style Pass-by-Value and Pass-by-Reference Output Parameters Managed Pointers Variable Argument Methods Methods, Subclassing Virtuals, Overriding New Slots Exception Handlers Constructors, Instantiation § Default Constructors Value Construction Constructor Chaining Field Initialization Type Initializers Unhandled Exceptions Properties § Indexers Mixed Mode Accessibility Events Operator Overloading Coercion Subclassing, Polymorphism Styles of Inheritance § Implementation Inheritance Interface Inheritance Abstract Classes Interfaces § Method Dispatch Multiple Inheritance Private Interface Inheritance Private Inheritance Accessibility Interface Reimplementation Abstract and Interface? Sealing Types and Methods Runtime Type Checking Namespaces: Organizing Types § Define a Namespace Namespace Resolution Special Types § Delegates § CTS Support Co- and Contravariance Anonymous Delegates Custom Attributes Enumerations § Flags-Style Limitations Helper Methods Generics § Further Reading §

This Book Reviewed!

© 2006 Wiley Publishing Inc.

Interfaces

An interface is a special type containing no method implementations but that can be used by other types to declare support for some set of public APIs. For example, the following interface defines a method and three properties:

interface ICollection : IEnumerable
{
   void CopyTo(Array array, int index);
   int Count { get; }
   bool IsSynchronized { get; }
   object SyncRoot { get; }
}

It is customary to name interfaces to start with a capital I, a throwback to the days of COM. All interfaces in COM—also by convention—started with I.

Much like abstract methods on an abstract class, we don’t specify implementations for members; unlike abstract classes, an interface cannot contain any implementations whatsoever. Notice also that the interface itself derives from another interface. An interface which derives from another interface inherits the interface of all members on the base interface, meaning that an implementer must supply concrete versions of both the base interface’s and the new interface’s members.

When a type implements an interface, it must provide support for the entire interface. Although, you can use an abstract class and avoid implementing specific members by marking them abstract. This type can then be referenced by and accessed polymorphically through variables typed as that interface. This is pure interface inheritance, as there are no implementations inherited. For example, consider this example of a simpler interface and an example implementation:

interface IComparable { int CompareTo(object obj); } struct Int32 : IComparable { private int value; public int CompareTo(object obj) { if (!(obj is int)) throw new ArgumentException(); int num = (int)obj; if (this.value < num) return -1; else if (this.value > num) return 1; return 0; } // ... } With this definition, an instance of Int32 can be used wherever an IComparable was expected, for example as an argument to a method, to store in a local variable or a field, and so on. The same is true of any base types the interface derived from. For example, ICollection implements IEnumerable; thus, anything that implements ICollection can be treated as either an ICollection or an IEnumerable. Because Int32 is a struct, it must be boxed before it can be passed around as an IComparable.

There are a few additional interesting things to note:

The fact that a type implements an interface is part of its public contract. This means any methods implemented for that interface must be public. The one instance where this isn’t the case is with private interface implementation, detailed further below, in which case the method is still accessible through interface method calls but is actually still private.

You can choose whether to mark the implementing methods as virtual or leave them with the default of final. Note that because of interface reimplementation, discussed below, you can never prevent further derived subclasses from creating new method slots for the same interface.