Implementing an Interface

Once we've defined an interface such as ITeacher, we can set about designating various classes as being teachers—for example, Professors, or Students, or generic Person objects—simply by declaring that the class of interest implements the ITeacher interface using the syntax shown here:

// Implementing an interface ...
public class Professor : ITeacher
{
  // details omitted ...
}

Note that the syntax for declaring that a class is implementing an interface is indistinguishable from the syntax that indicates inheritance—a colon followed by the interface/base class name:

// Extending a class via inheritance ...
public class Professor : Person
{
  // details omitted ...
}

Once a class declares that it is implementing an interface:

public class Professor : ITeacher { ...

the implementing class must provide concrete versions of all of the (implicitly abstract) methods declared by the interface in question in order to satisfy the compiler. As an example, let's say that we were to code the Professor class as shown in the following code, implementing three of the four methods called for by the ITeacher interface but neglecting to code the fourth method:

public class Professor : ITeacher
{
  private string name;
  private string employeeId;
  // etc.

  // Properties defined; details omitted.

  // We implement three of the four methods called for by the
  // ITeacher interface, to provide method bodies.

  public bool AgreeToTeach(Course c) {
    // Logic for the method body goes here; details omitted.
  }

  public void DesignateTextbook(TextBook b, Course c) {
    // Logic for the method body goes here; details omitted.
}
  public Syllabus DefineSyllabus(Course c) {
    // Logic for the method body goes here; details omitted.
}

  // Note that we've failed to provide an implementation of the
  // ApproveEnrollment method ...
}

If we were to try to compile this class as shown previously, we'd get the following compiler error:

error CS0535: 'Professor' does not implement interface
member 'ITeacher.ApproveEnrollment(Student, Course)'

Another Form of "Is A" Relationship

You learned in Chapter 5 that inheritance is thought of as the "is a" relationship. As it turns out, implementing an interface is another form of "is a" relationship:

• If the Professor class extends the Person class, then a professor is a person; and

• If the Professor class implements the ITeacher interface, then a professor is a teacher.

Also, when a class A implements an interface X, all of the classes that are derived from A may also be said to implement that same interface. For example, if we derive a class called AdjunctProfessor from Professor, then if Professor implements the ITeacher interface, an adjunct professor is a teacher.

public class Professor : ITeacher
{
  // All methods required by ITeacher will be implemented by this class ...
  // details omitted.
}

public class AdjunctProfessor : Professor
{
  // All methods required by ITeacher will be, at a minimum, inherited from
  // Professor ... details omitted.
}

This makes intuitive sense, because AdjunctProfessor will either inherit all of the methods called for by the ITeacher interface from Professor, or will override them; but, either way, an AdjunctProfessor will be "equipped" to perform all of the services required of an (I)Teacher.

Abstract Classes vs. Interfaces

Implementing an interface is conceptually similar to having to "flesh out" abstract methods when extending an abstract class. What are the differences, then, between implementing an interface vs. extending an abstract class? Why might we wish to use one approach over the other when designing an application?

• With an interface, we specify abstract behaviors only, whereas an abstract class often specifies a "concrete" data structure (attributes) as well as a mixture of abstract and concrete behaviors. So, in terms of the "abstractness spectrum," an interface is more abstract than an abstract class (which is in turn more abstract than a concrete class) because an interface leaves even more details to the imagination.

  Note?/td>

  Note that an abstract class can be merely a set of abstract method headers if we wish to design it as such; for example: public abstract class Person { // We are purposely declaring NO ATTRIBUTES for this class ... // ... and ALL of our methods are abstract. public abstract void Print(); public abstract double ComputeSalary(); // etc. } However, in such a situation, the preferred approach would be to simply declare an interface instead.

• When a nonabstract class is derived from an abstract class, the derived class provides a concrete implementation of abstract methods declared in the abstract class by overriding them. The derived class method headers therefore must include the override keyword.

• When a class implements an interface, the implementing class must once again provide a concrete implementation of all of the methods declared in the interface. However, the implementing class doesn't override them. Rather, we're defining the methods for the first time from scratch, and so the override keyword isn't included in the implementing class method headers. (If we were to try to apply the override keyword, the compiler would inform us that it has "found no suitable method to override.")

• The syntactical differences in these two approaches are compared side-by-side here:

  Example Using an Abstract Class	Example Using an Interface
  Declaring the Teacher Type as an Abstract Class: public abstract class Teacher { // Abstract classes may declare // data structure. string name; string employeeId; // etc. // We declare abstract methods using // the "abstract" keyword. public abstract void AgreeToTeach( Course c); public abstract void DesignateTextbook( TextBook b, Course c); // etc. // Abstract classes may declare concrete // methods. public void Print() { Console.WriteLine(name); // etc. } }	Declaring the Teacher Type as an Interface: public interface ITeacher { // Interfaces may not declare // attributes. // We can't use the "public" or // "abstract" keywords. void AgreeToTeach(Course c); void DesignateTextbook( TextBook b, Course c); // etc. // Interfaces may not declare concrete // methods. }
  Deriving Professor from Teacher: public class Professor : Teacher { // Professor inherits attributes, if any, // from parent class, and optionally // adds additional attributes; details // omitted. // We override abstract methods inherited // from the Teacher class. public override void AgreeToTeach( Course c) { // Logic for the method body goes here; // details omitted. } // etc. for other abstract methods. // Additional methods may be added; // details omitted. }	Professor Implements ITeacher: public class Professor : ITeacher { // Class must provide its own data // structure, as an interface // cannot provide any. string name; string employeeId; // etc. // We implement the methods from the // ITeacher interface without using // the override keyword. public void AgreeToTeach(Course c) { // Logic for the method body goes here; // details omitted. } // etc. for other abstract methods. // Additional methods may be added; // details omitted. }

• A class that is derived from an abstract class needn't override all of the abstract methods it inherits with concrete versions; if one or more of the abstract methods is inherited "as is," then the derived class must also be declared abstract.

• In contrast, a class that implements an interface must provide concrete versions of all abstract methods required of the interface; implementing an interface is an "all or nothing" proposition.

• Another important distinction between extending an abstract class vs. implementing an interface is that whereas a given class may only be derived from one immediate base class, a class may implement as many interfaces as desired. Because this is such a powerful language feature, we'll illustrate it with an example in the next section.

Implementing Multiple Interfaces

As an example, if we were to invent a second interface called IAdministrator, which in turn specifies the following method headers:

public interface IAdministrator
{
  public bool approveNewCourse(Course c);
  public bool hireProfessor(Professor p);
}

we could then declare that a class such as Professor implements both the ITeacher and IAdministrator interfaces, in which case the class would need to implement all of the methods declared by both of these interfaces collectively:

public class Professor : ITeacher, IAdministrator
{
  // The Professor class must implement all of the methods called for by
  // the ITeacher interface ... details omitted.

  // The Professor class must implement all of the methods called for by
  // the IAdministrator interface ... details omitted.
}

When a class implements more than one interface, its objects are capable of assuming multiple identities or roles in an application; such objects can therefore be "handled" by various types of reference variables. Based on the preceding definition of a Professor as both an ITeacher and an IAdministrator, the following client code would be possible:

// Instantiate a Professor object, and store its handle in a reference
// variable of type Professor.
Professor p = new Professor();

// We then declare reference variables of the two types of interfaces that the
// Professor class implements.
ITeacher t;
IAdministrator a;

t = p; // We store a handle on the Professor in a reference variable of
       // type Teacher; this is possible because a professor IS A teacher!

a = p; // We store a handle on the Professor in a reference variable of
       // type Administrator; this is possible because a professor IS AN
       // administrator!

as illustrated conceptually in Figure 7-4.

Figure 7-4: The Professor object has three different identities.

This is conceptually the same thing as you, as a person, being viewed as having different roles by different people: you're viewed as an employee by your manager, as a son or daughter by your parents, perhaps as a parent by your children, and so forth.

We may then command the same object either as a Professor …

// Department is a property defined for the Professor class ...
p.Department = "Computer Science";

or as a Teacher …

// AgreeToTeach is a method defined for the ITeacher interface ...
t.AgreeToTeach(c); // Note that p.agreeToTeach(c); also works ...

or as an Administrator …

// ApproveNewCourse is a method defined for the IAdministrator interface ...
a.approveNewCourse(c); // Note that p.approveNewCourse(c); also works ...

because it's all three, rolled into one!

A class may simultaneously extend a single base class and implement one or more interfaces, as follows:

public class Professor : Person, ITeacher, IAdministrator { ... }

Under such circumstances, the name of the base class will always come first in the list, followed by the names of all interfaces to be implemented. As we discussed in Chapter 5, C# doesn't support multiple inheritance, and so it isn't possible to list more than one class name after the colon; assuming that Professor and Student are both classes, the following wouldn't compile:

// This would not compile.
public class StudentTeacher : Professor, Student, ITeacher
{
  // details omitted
}

The preceding code would produce the following compilation error:

error CS0527: 'Student' type in interface list is not an interface

In other words, the compiler will only consider the first entry after the colon as a base class and everything else in the list is assumed to be an interface.

Interfaces and Instantiation

Interfaces can't be instantiated, because there is no such thing as a constructor for an interface. That is, if we define ITeacher to be an interface, we may not try to instantiate it directly:

ITeacher t = new ITeacher();  // Impossible! The compiler will generate an error
                              // on this line of code.

We'd get the following compilation error on the preceding line of code:

error CS0144: Cannot create an instance of the abstract class or
interface 'ITeacher'

While we're indeed prevented from instantiating an interface, we're nonetheless permitted to declare reference variables to be of an interface type, as we saw earlier:

ITeacher t;  // This is OK.

We could, therefore, do the following:

ITeacher t = new Professor();

Why is this permitted? The compiler allows assignments to occur if the type of the expression to the right of the equal sign (=) is a type that is compatible with the variable to the left of the equal sign. Since Professor implements ITeacher, a professor is a teacher, and so this assignment is permitted.

The Importance of Interfaces

Interfaces are one of the most poorly understood, and hence underutilized, features of the OOPLs that support them. This is quite unfortunate, as interfaces are extremely powerful if utilized properly.

Whenever possible/feasible, design the public aspects of your classes using interface types instead of specific class types to allow for greater flexibility/utility of your methods, to include

• Formal parameters to methods

• Method return types

Let's use two different examples to illustrate the power of interfaces.

public class Course
{
  private Professor teachingAssistant;

  // Other features omitted ...

  public Professor TeachingAssistant {
    get {
      return teachingAssistant;
    }
    set {
      teachingAssistant = value;
    }
  }

  // Other features omitted ...
}

// Client code.
Course c = new Course("Math 101");
Professor p = new Professor("John Smith");
c.TeachingAssistant = p;

public class Course
{
  // Change type from Professor to Student here ...
  private Student teachingAssistant;

  // ... and here.
  public Student TeachingAssistant {
    // Details omitted ...
  }

  // etc.
}

// Client code.
Course c = new Course("Math 101");
Professor p = new Professor("John Smith");
c.TeachingAssistant = p;  // This line of code will no longer compile.

public class Course
{
  private ITeacher teachingAssistant;
  // details omitted ...
  public ITeacher TeachingAssistant {
    // details omitted ...
  }

  // etc.
}

// Client code
Course c = new Course("Math 101");
Professor p = new Professor("John Smith");
c.TeachingAssistant = p;

// Client code
Course c = new Course("Math 101");
Student s = new Student("George Jones");
c.TeachingAssistant = s;

int Add(object value)
void Clear()
bool Contains(object value)
int IndexOf(object value)
void Insert(int index, object value)
void Remove(object value)
void RemoveAt(int index)

public class SomeClass
{
  // details omitted ...

  public void SomeMethod(IList list) {
    // Within this method, we can manipulate the list argument with any of the
    // methods defined by the IList interface ...
  }
}