When we introduced collections previously, we spoke of a type of data structure that supports a specified set of operations: add, remove, size, etc.

Each operation has a specified set of input and output, and usually some description of how the operation functions.

We would thus demand that any data structure that wishes to call itself a collection must support those operations. Once this demand is satisfied however, we can use this structure with the full knowledge that we have access to the specified operations.

Some 'real-world' examples

Containers

• A container is an object that can hold things. (We're talking ShopRite here folks, not Java).
  • We expect to be able to add and remove other things to and from the container.
• The container could be a shopping bag, a cardboard box, a plastic bin, a brown bag, a shopping cart, a car trunk.
• Once we know we are dealing with a container, we understand its basic workings.
  • (If at the checkout counter, we ask if they have a box instead of a bag, they may not have one or are unwilling to give you one, but they understand you-- both the bag and box are containers.)
• Besides the basic operations of add/remove, the various containers may have their own individual characteristics.
  • The plastic bin has a lid and can be closed
  • The shopping bag has a handle and can be lifted.
• However, from the point of view of them all being containers, we know we can add and remove items.

Cars

• Cars have certain standardized features
  • An ignition key
  • Lights
  • Accelerator and brake pedals (in a certain configuration)
  • A steering wheel (in a certain configuration)
  • Wipers
• To be a car, the vehicle must conform to the specification of a 'car'
• Particular cars may have other characteristics
  • Cruise control
  • Power steering
  • Intermittent wipers
• Whether or not the extra features are present, all that counts to be a car is the 'car' specification

Phones

• A phone has the specification of being able to dial and make a call.
• To be a phone, the device must conform to that specification
• A particular device may have other features as well
  • Camera phones
  • Blackberrys
  • MP3-capable phones
  • All are phones
• But regardless of the other features, when viewed as a phone, all that matters is the 'phone' speicfication

Interfaces in Java

• An interface in Java is nothing more than a set of method prototypes, specifying the required operations.
• The keyword interface is used (instead of class to introduce the set of method specs

  interface Collection {		// in java.util
  	boolean add(Object obj);
  	...
  	boolean isEmpty();
  	...
  	boolean remove(Object obj);
  	...
  	int size();
  }
  		

  interface Compareable {		// in java.lang
  	int compareTo(Object obj);
  }
  		

  interface Iterable {  		// in java.lang 
  	Iterator iterator();
  }
  		

• We speak of implementing the interface, i.e., fulfilling the requirement of providing the specified methods (operations).
  • This is achieved by providing definitions (i.e., method bodies) for the specified methods.
  • An interface is implemented via a class definition
    The methods (which have bodies) of the class provide the implementation
  • We use the keyword implements to indicate that the class intends to fulfill the interface requirements.

  class String implements Compareable {
  	...
  	String concat(String s) {...}
  	...
  	int compareTo(Object obj) {...
  		// code to compare String's
  		...
  	}		
  	...
  	String subString(int start) {...}
  	... 
  }
  		

  class Simple implements Collection {			 
  	boolean add(Object obj) {return false;}
  	boolean remove(Object obj) {return false;}
  	boolean isEmpty() {return true;}
  	int size() {return 0;}
  }