6. Interfaces, Delegates, and Reactive Systems¶

6.1.1. Interfaces as “Data Types”¶

Say we are assembling a computerized card game, where a dealer deals cards to players. Some players are human, some are computer players — they’re mixed together. Regardless of the form of player, the dealer will ask a player if it wants a card, and if yes, deal it one.

We might try this awkward coding of class Dealer:

// dealer for a card game of one human and one computer player:
public class Dealer {
  private HumanPlayer h;
  private ComputerPlayer c;
  private CardDeck d;  // deck of cards; has a  dealNewCard  method

  public Dealer(HumanPlayer h, ComputerPlayer c) {  this.h = h;  this.c = c; }

  public void PlayOneRound() {
    // ...
    while (h.wantsCard()) {
      h.getsCard(d.dealNewCard());
    }
    while (c.wantsCard() {
      c.getsCard(d.dealNewCard());
    }
    // ...
  }
}

The duplicate code is bad, since both the human and computer objects are called the same way. Here is the situation, summarized in a class diagram:

We can improve this by using an interface:

// a  Player  is any class that has these two methods with
//   the behaviors described in the comments:
public interface Player {
  // wantsCard  returns true when the Player wants another card:
  public bool wantsCard();
  // getsCard(c)  adds Card  c  to the hand held within the Player:
  public void getsCard(Card c);
}

The interface describes the “type of class” that can be a player in the card game. We code class HumanPlayer and class ComputerPlayer to have the methods listed in the interface:

// HumanPlayer is the computerized "proxy" for the human;
//   it _implements_ (matches) interface Player:
public class HumanPlayer : Player {     // READ THIS LINE CAREFULLY!
  private HandOfCards h;
  // other fields
  // ...

  public bool wantsCard() {
    Console.WriteLine("Do you want another card?");
    string answer = Console.ReadLine();
    return (answer == "Yes");
  }

  public void getsCard(Card c) { h.add(c); }

  // other methods
  // ...
}

// ComputerPlayer is a computer card player; it also implements Player:
public class ComputerPlayer : Player {
  private HandOfCards h;
  // other fields
  // ...

  public bool wantsCard() {
    return (h.score() < 17)
  }

  public void getsCard(Card c) { h.add(c); }

  // other methods
  //...
}

The two classes implement Player — they have “data type” Player. The Dealer is simplified to deal to Player s:

// dealer for a card game of Players:
public class Dealer {
  private List<Player> players;          // the players of the game
     // we use the interface name as the "data type" of the players
  private CardDeck d;     // the deck of cards

  // construct dealer:  pl  is a list of the Player objects
  //   that the dealer contacts
  public Dealer(List<Player> pl) {  players = pl; }

  // plays one round of the card game with the  players:
  public void PlayOneRound() {
    // ...
    foreach(Player p in players) {
      while (p.wantsCard()) {
        p.getsCard(d.dealNewCard())
      }
    }
    // ...
  }
}

The coding is simpler and more general. Here is the class diagram, showing how class Dealer is coded to depend on Player. On the “other side” of the interface, HumanPlayer and ComputerPlayer implement (“plug into”) the interface:

Either or both of ComputerPlayers and HumanPlayers can “plug into” a Dealer through the interface.

6.1.2. Interfaces as Connection Points¶

We use interfaces every day — we call them “specifications” or “sizes” — What size of shoe do you wear? (8 narrow? 9 1/2 wide?) What type of battery do I need for my flashlight? (1.5 volt AAA?) What kind of “dingle” do I need to connect this darned VGA cable to my MacBook?

The brand of shoe or battery or cable is unimportant — the specification is what matters. An interface is a specification for a class you want to connect to — it is a “connection point” or “plug-in point”.

Here is the typical software situation: A big software system must be divided into subassemblies, and each subassembly is built by a separate team. The teams work at the same time. How can a team compile, build, and test its subassembly without the other subassemblies? How do we ensure that the completed subassemblies connect together correctly?

Answer: We use interfaces to define the connection points where one assembly connects (“plugs in”) to another. Here is a diagram of three assemblies that connect together via two interfaces:

Now, the Assembly1 team can code and compile its own part of the system, because they use interfaces ConnectionPointA and ConnectionPointB in their coding. The team can even test their code by writing a simple, “dummy” (mock) class that implements ConnectionPointA and running their tests with it. When it’s time to combine the three subassemblies, the code projects link together because all three were coded to match the two interfaces. This is how system building is done.

Here are three examples of “plug-in” interfaces that you have likely used:

1. Data structure plug-ins: If you have dared to look at the .NET library, you know there is a huge collection of data-structure classes, some graphics-based, some storage-based, far too many to remember. Many of the data-structure classes have similar abilities (methods), and they use the same method names for doing the same actions. Interfaces are used to organize together those classes that do “the same thing”.

   Look at the .NET reference page for System.Collections. First, you see the names of the basic data structures supported by C#. Next, you see the interface s that are used to describe the “types” of data structures, e.g.,

   Interface	Description
   ICollection	Defines size, enumerators and synchronization methods for all collections.
   IComparer	Exposes a method that compares two objects.
   IDictionary	Represents a collection of key-and-value pairs.
   IDictionaryEnumerator	Enumerates the elements of a dictionary.
   IEnumerable	Exposes the enumerator, which supports a simple iteration over a collection.
   IEnumerator	Supports a simple iteration over a collection.
   IHashCodeProvider	Supplies a hash code for an object, using a custom hash function.
   IList	Represents a collection of objects that can be individually accessed by index.

   ---

   If you click on any of the interface names (try IList, the “data type” of collections that are sequential and are indexed by non-negative ints), you will see the definition of the interface and the data structures that implement the interface.

   Another important interface is IDictionary, the “data type” of table-like data structures that use (non-int) keys for lookups.

   Say you are building an assembly that relies on a table, but you do not want to commit to a particular coding of a table — maybe it does not matter or maybe you want to leave this work to an expert — then you code your assembly to depend on the IDictionary interface. The idea looks like this:

   

   That is, within the assembly, the table, no matter how it is implemented, can be indexed and assigned to and can be called with the methods, Add, Clear, Contains, etc. (see the methods listing in the .NET documentation).

   The assembly’s code might be integrated like this:

    // Main assembles my system:
    public void Main() {
      // define the system's main table:
      IDictionary main_table = new Hashtable();
      // or maybe:   IDictionary main_table = new HybridDictionary();
      // or any of the classes listed at
      //   http://msdn.microsoft.com/en-us/library/system.collections.idictionary_methods(v=vs.110).aspx
   
      // plug the main_table into the constructed assembly:
      Assembly my_assembly = new Assembly(main_table);
      // do more assembly work and start the system:
      // ...
      myassembly.run();
   }
   

2. Subassembly plug-ins: Your company builds business systems (“Enterprise Information Systems”), which are structured like this:

   GUI ---> BusinessLogic ---> Database
   

   The user talks to the GUI, which relays commands to the Business Logic, which translates the commands into Database operations.

   GUIs are tricky to implement well, and specialists write these. Databases are also tricky to build, and specialists write these. Your company specializes in writing the Business-Logic assembly which understands the needs and commands of the user: You are given an interface for communicating with the GUI and an interface for communicating with the database, and you use these interfaces to write the Business Logic:

   

   You “plug” a UserInterface and a Database into the Controller.

   Your assembly must also have an interface so that your assembly can “plug” into the one that receives user inputs. (You can think of the - - -> arrows into the UserInterface and the Database interface as “sockets” and the ---|> arrow out of the assembly to ControllerInterface as a “plug with pins” that fits into a socket.)

   You test your Controller subassembly with simple-minded class-codings that implement the two interfaces and you “plug” your assembly into a test harness that generates calls to the handle_Input method. This assembly testing will minimize the headaches of testing the entire system when it is assembled with the actual subassemblies.

3. Network plug-ins: When networks became popular, so did Client-Server systems, where a client computer logs in and does business with a server computer — in this way, a company’s computers can share a common file system or data base. For clients to share a server, there must be standard methods for logging in, transferring data, etc. CORBA (Common Object Request Broker Architecture) is a standardized collection of interfaces that a Client server must implement to talk to a server. (A server computer has its own set of interfaces to implement to be a server.)

   The Client computer and Server computer connect through a piece of code called the Object Request Broker (ORB), that understands the Client and Server interfaces and so can match Client to Server for communication.

   You can read a simple description and see a simple diagram at the Wikipedia page for CORBA. CORBA’s interfaces make it easy for businesses to communicate with each others’ servers. And web-based internet commerce (e.g., Amazon.com) is based on a similar set of interfaces that define the TCP/IP network protocol.