CISC 3115 — Lecture 6

CISC 3115
Modern Programming Techniques
Lecture 6
Interfaces

If it looks like a duck, walks like a duck, and sounds like a duck … All surgeons are doctors, but not all doctors are surgeons

Interfaces: Overview

Interface

General Usage

A point where two systems, subjects, organizations, etc. meet and interact.

Computing

Interface (computing): In computing, an interface is a shared boundary across which two or more separate components of a computer system exchange information. The exchange can be between software, computer hardware, peripheral devices, humans, and combinations of these.

In Object-Oriented Programming (OOP)

Interface (object-oriented programming)

In object-oriented programming, an interface is a data type that acts as an abstraction of a class. It describes a set of method signatures, the implementations of which may be provided by multiple classes that are otherwise not necessarily related to each other. A class which provides the methods listed in a protocol is said to implement the interface.[1]

If objects are fully encapsulated then the interface is the only way in which they may be accessed by other objects. For example, in Java, the Comparable interface specifies a method compareTo() which implementing classes must implement. This means that a sorting method, for example, can sort a collection of any objects of types which implement the Comparable interface, without having to know anything about the inner nature of the class (except that two of these objects can be compared by means of compareTo()).

In Java

Interface (Java)

An interface in the Java programming language is an abstract type that is used to declare a behavior that classes must implement. Interfaces are declared using the interface keyword, and may only contain method signature and constant declarations (variable declarations that are declared to be both static and final). All methods of an Interface do not contain implementation (method bodies) as of all versions below Java 8.

Interfaces cannot be instantiated, but rather are implemented. A class that implements an interface must implement all of the methods described in the interface, (or be an abstract class). Object references in Java may be specified to be of an interface type; in each case, they must either be null, or be bound to an object that implements the interface.

(One benefit of using interfaces is that they simulate multiple inheritance. All classes in Java must have exactly one base class, the only exception being java.lang.Object (the root class of the Java type system); multiple inheritance of classes is not allowed. However, an interface may inherit multiple interfaces and a class may implement multiple interfaces.)

Change of Representation: Social Security Number

Modelling Social Security Numbers

Let us introduce a class that represents social security numbers.

We'll keep it simple: a social security number is a 9 digit value separated into 3 sections by dashes (-).
The three sections are known as the area, group, and serial respectively, and are 3, 2, and 4 digits respectively as well.
In line with keeping things simple, we'll restrict the behavior of the class to printing an ssnum, and retrieving any of its three sections

Specification of Behavior

class SSNum {
	…

	public int getArea() {…}
	public int getGroup() {…}
	public int getSerial() {…}

	public String toString() {…}
	…
}

Notes

The (public) methods are referred to as the behavior of the class
The (private) instance variables are referred to as the state of the class
Initially, we are interested in the behavior of the class, i.e., how the user (the client) of the class interacts with objects of the class.
Strictly speaking, it is only after we have determined the behavior that we flesh out the state (variables)
- It does turn out however, that the fleshing out of details may form feedback that in turn may influence the behavior somewhat
In the above code, we have specified the interface of the class (i.e., the manner in which users of the class interact/interface with objects of the class), but not its implementation (its internal representation).

Choosing the Internal Representation

We decide to represent the ssnum as a String, complete with the separating '-'s.

The choice of state (i.e., the variables; the way we intend to represent the information maintained by the class) drives the logic (bodies/implementation) of the methods.
We decide on the '-'-separated string as the input to our constructor.
- We could add additional constructors to allow the creation of an ssnum using alternative formats (e.g., a simple integer)
Similarly we choose the '-'-separated string for toString.
- This is probably a bit more obvious; regardless of how we maintain the social security number internally, we in all likelihood want to print it 'as a social security number', i.e., with the '-'s in the usual places.

class SSNum {
	SSNum(String ssnum) {this.ssnum = ssnum;}

	public int getArea() {return Integer.parseInt(ssnum.substring(0, 3));}
	public int getGroup() {return Integer.parseInt(ssnum.substring(4, 6));}
	public int getSerial() {return Integer.parseInt(ssnum.substring(7));}

	public String toString() {return ssnum;}
	
	private String ssnum;
}

Notes

As can be seen above, once we choose the internal representation of the class' state, the logic of the behavior (methods) becomes to some extent a given.
- that should not be a surprise; one usually chooses a internal representation because of its impact on the implementation of the methods
Integer.valueOf is an acceptable alternative to parseInt
- the former returns an Integer, the latter an int, but with autoboxing, the result is basically the same (at least here)

Coding a Demo App for our Class

Just a short application to demonstrate the behavior of the class

class SSNumApp {
	public static void main(String [] args) {
		SSNum sSNum = new SSNum("123-45-6789");

		System.out.println(sSNum);
		System.out.println(sSNum.getArea());
		System.out.println(sSNum.getGroup());
		System.out.println(sSNum.getSerial());
	}
}

A Change of Implementation (Representation)

We decide we'd like to change our implementation (i.e., internal representation) to an int (e.g., it takes up less space than the 11-byte string).

class SSNum {
	SSNum(String ssnum) {
		this.ssnum = Integer.parseInt(ssnum.substring(0, 3)) * 1000000  + Integer.parseInt(ssnum.substring(4, 6)) * 10000 + Integer.parseInt(ssnum.substring(7));}

	public int getArea() {return ssnum / 1000000;}
	public int getGroup() {return (ssnum / 10000) % 100;}
	public int getSerial() {return ssnum % 10000;}

	public String toString() {return String.format("%03d-%02d-%04d", getArea(), getGroup(), getSerial());}
	
	private int ssnum;
}

Notes

The behavior (specification/signatures of the public methods) remains the same.
As before, the logic details of the methods are irrelevant to our discussion, but notice that they ARE quite different due to the change in representation — both the public methods as well as the constructor and toString
- This all makes sense, and is in keeping with our discussion above … while the behavior remains the same, the means of achieving them is heavily dependent on the internal representation
- The constructor has to transform the parameter into the internal format
- Similarly, toString has to transform the internal representation into a String
- It is often (usually?) the case that a change in implementation will affect the constructors, which accept arguments and transform them into the internal representation; and the toString which takes the internal representation and transforms it into a string suitable for human viewing.

The Demo App Remains Unchanged

We used the same name for the new class (i.e., we replaced the old implementation with the new)
The behavior (public methods) is the same, and we are constrained to work with those methods

Some Issues

The following may not be compelling arguments just yet, but they help set the stage for what is coming.

Suppose we had named our original class StringSSNum. When we shift to an int-based implementation, that name would no longer be appropriate.
On the other hand, using the same name for the change of implementation, means you can't have both classes in the same application
- There's not much reason to do so in the above example, but there are other situations where you might want to have them both around (see the Sorting example below for a bit more elaboration)
Using different names for the two classes also means that any application code (i.e., code that uses this class) would have to change to refer to the new class name.
- All code that creates an object of one of the classes has to be changed when moving to the other implementation; for example, assuming we started off with StringSSNum, the app would read:
```
StringSSNum sSNum = new StringSSNum("123-45-6789");
			
```
  would have to be changed to:
```
IntSSNum sSNum = new IntSSNum("123-45-6789");
			
```
  (note that I've left the variable name the same 'vanilla' name (ssNum); changing it from stringSSNum to intSSNum just introduces even more name changing.)
  - One of the objectives of object-oriented programming (OOP) (and to an extent, programming in general) is to minimize changes to code that isn't directly affected by a change. In our situation, the application code is changing even though we're employing the exact same behavior.
Finally, it will often be the case that a particular implementation class may have methods that are specific to the implementation; changing to a different implementation that doesn't provide those methods can break the application
- To some extent this is the most important issue, though it cannot be made compelling with our simple example; it will have to wait for later situations
- A weak example might be if there was a convertToInt method in our StringSSNum implementation:
```
int convertToInt() {…}
				
```
  - Even though, the internal representation should be of no concern to the outside, the naive programmer who designed and coded StringSSNum may have thought it a good idea to have such a method; and furthermore, made heavy use of this method
  - If we now change implementations (to IntSSNum) — which justifiably would not have such a method, the application code would break wherever that method was called.
    - We can repair this easily enough (simply add the method to IntSSNum) but that then involves making changes to our tested class.
    - The name of the method is inappropriate as well; if anything, a method named asInt would be less egregious, and could be argued to be appropriate under all implementations.

The upshot is that in situations where there is a clear set of behavior, and potentially more than one implementation, we should strive to limit ourselves to the common behavior.

Interfaces

The following is a standard approach to coding robust and flexible software, and, in particular the sort of coding we will be doing in this course.

Java's interface construct allows us to specify a set of behavior in the form of method specifications. The interface forms a data type, i.e., a specification of a set of values and the valid operations on those values. Any class that implements the interface is said to belong to the data type of the interface, i.e., an object of the implementation class is-a object of the interface type as well, and can appear in any context interface reference variables appear. Here is an interface for our social security number:

interface SSNum {
	int getArea();
	int getGroup();
	int getSerial();
}

Notes

The interface construct consists of a sequence of method headers.
- As you can see, they correspond to our original behavior for our class.
Any class implementing this interface must supply implementations (i.e., method bodies) for all of the specified header.
No constructors are specified … an interface cannot be created (it has all this unspecified behavior); only an implementing (i.e., concrete) class can be created

Implementations of the Interface

We now restate our two implementations in terms of the interface:

class StringSSNum implements SSNum {
	StringSSNum(String ssnum) {this.ssnum = ssnum;}

	public int getArea() {return Integer.parseInt(ssnum.substring(0, 3));}
	public int getGroup() {return Integer.parseInt(ssnum.substring(4, 6));}
	public int getSerial() {return Integer.parseInt(ssnum.substring(7));}

	public String toString() {return ssnum;}
	
	private String ssnum;
}

class IntSSNum implements SSNum {
	IntSSNum(String ssnum) {this.ssnum = Integer.parseInt(ssnum.substring(0, 3)) * 1000000 + 
										Integer.parseInt(ssnum.substring(4, 6)) * 10000 + Integer.parseInt(ssnum.substring(7));}

	public int getArea() {return ssnum / 1000000;}
	public int getGroup() {return (ssnum / 10000) % 100;}
	public int getSerial() {return ssnum % 10000;}

	public String toString() {return String.format("%03d-%02d-%04d", getArea(), getGroup(), getSerial());}
	
	private int ssnum;
}

The Apps

class StringSSNumApp {
	public static void main(String [] args) {
		StringSSNum stringSSNum = new StringSSNum("123-45-6789");

		System.out.println(stringSSNum);
		System.out.println(stringSSNum.getArea());
		System.out.println(stringSSNum.getGroup());
		System.out.println(stringSSNum.getSerial());
	}
}

class IntSSNumApp {
	public static void main(String [] args) {
		IntSSNum intSSNum = new IntSSNum("123-45-6789");

		System.out.println(intSSNum);
		System.out.println(intSSNum.getArea());
		System.out.println(intSSNum.getGroup());
		System.out.println(intSSNum.getSerial());
	}
}

Notes

The two apps are identical, modulo:
- The names of the type (StringSSNum vs IntSSNum). This is used in
  - declaring the reference variables of the objects (e.g., IntSSNum intSSNum).
    - We'll see how to solve this in the next section
  - creation of the object (e.g., new StringSSNum(…);).
    - This will take a touch more work; but its solution will introduce a powerful OOP technique
- The names of the variables (stringSSNum vs intSSNum)
  - These are 'arbitrary' … there's no reason we don't use the variable name ssNum in both apps.

Programming to the Interface

An interface specifies the required/recommended behavior (set of methods) via which one interacts with any class implementing the interface.

An application restricting itself to the interface is impervious to implementation changes (i.e., a change of implementation or a change within the currently used implementation).
Each implementation may have (non-private) methods outside of the interface; using such methods opens up the application to breaking in the event of a change to the implementation.
The alternative to programming to the interface is called programming to the implementation or programming to classes

Revisiting our Apps

As we mentioned, the apps for the two ssnum implementations are identical except for the creation of the objects and the variable names.

The latter is trivial to rectify; simply name them the same, i.e., ssNum.
- and this would be in keeping with your notion of concentrating on the interface; we're not interested in intSSNums or stringSSNum's; from the interface POV, they're both simply ssNums
The creation of the object is a bit more challenging, to create an IntSSNum one must write new IntSSNum, (clearly one wouldn't write new StringSSNum and you can't create an SSNum (it's an interface, not a concrete class).
- The solution is to isolate the common code from the implementation-specific stuff. The common code goes into an SSNum app
  - Rather than creating the ssNum object (which would require stating what sort of implementing object we're creating, i.e., newIntSSNum or new String SSNum), we pass the object in as a parameter, allowing the caller to be responsible for which to use.
    - this works since both implementations is-a SSNum by virtue of their having implemented the SSNum interface.
  - By placing the common stuff in the SSNum app, we are also making sure we are only using those methods of the interface, i.e., we are indeed 'programming to the interface'.
- This technique is an elegant and fairly advanced modern object-oriented programming approach called dependency injection
  - Dependency injection is the process of an external entity supplying dependencies (i.e., the objects to be used for which there are various choices as to their selection). This is a technique of a design principle known as inversion of control in which (loosely speaking) responsibility for decisions are shifted from a piece of code to its caller.

class SSNumApp {
	public static void demo(SSNum sSNum) {
		System.out.println(sSNum);
		System.out.println(sSNum.getArea());
		System.out.println(sSNum.getGroup());
		System.out.println(sSNum.getSerial());
	}
}

class StringSSNumApp {
        public static void main(String [] args) {
                SSNumApp.demo(new StringSSNum("123-45-6789"));
        }
}

class IntSSNumApp {
        public static void main(String [] args) {
                SSNumApp.demo(new IntSSNum("123-45-6789"));
        }
}

Change of Functionality: Counter

interface  Counter {
	void up();
	void down();
	int getVal();
}

public class UnboundedCounter implements Counter {
	UnboundedCounter() {val = 0;}

	public void up() {val++;}	
	public void down() {val--;}	

	public int getVal() {return val;}

	public String toString() {return "A counter with value " + val;}

	private int val = 0;
}

public class UpperBoundedCounter implements Counter {
	UpperBoundedCounter(int limit) {
		val = 0;
		this.limit = limit;
	} 

	public void up() {if (val < limit) val++;}	
	public void down() {val--;}	

	public int getVal() {return val;}
	int getLimit() {return limit;}

	public String toString() {return "A upper-bounded counter with value " + val + " and limit " + limit;}

	private int val = 0;
	private int limit;
}

public class App {
	public static void main(String [] args) {
		doIt(new UnboundedCounter());
		doIt(new UpperBoundedCounter(10));
	}

	static void doIt(Counter c) {
		System.out.println(c.getClass().getName());

		System.out.println("Initially: " + c);

		for (int i = 1; i <= 20; i++)
			c.up();
		System.out.println("After 20 up's: " + c);

		for (int i = 1; i <= 3; i++)
			c.down();
		System.out.println("After 3 down's: " + c);

		System.out.println();	//---------
	}
}

Notes

Both the UnboundedCounter as well as the UpperBoundedCounter can be sent as arguments to the Counter para,eter of doIt because they both implement the Counter interface and the thus considered Counter objects
- We say that UnboundedCounter is-a Counter (same for UpperBoundedCounter).
- We call this action (of being able to use an implementing class in the context of the corresponding interface) an
  upcast.
  - And as explained above, upcasts are always legal as the implementing class is-a object of the interface as well. Furthermore, no explicit cast is required.
Note that we cannot call UpperBoundCounter's getLimit method in doIt as it is not a method of the interface.
- To do this, we would have to first cast the Counter reference back to a UpperBoundedCounter. This would then permit getLimit to be called.
  - This is called a downcast, and requires an explicit cast in the code:
```
static void doIt(Counter c) {
	…
	UpperBounddedCounter ubc = (UpperBoundedCounter)c;
	System.out.println(ubc.getLimit();
	…
}
										
```
- However, while this would work for the UpperBoundedCounter argument, it would cause a ClassCastException when doIt was invoked with the UnboundedCounter argument.
  - The compiler allows the cast because it can potentially work — assuming that only references to UpperBoundedCounter objects were sent to doIt; however it requires an explicit cast to force the programmer to pay attention to the fact that this may fail.

If we view these three types (the interface and two implementing classes) as a hierarchy:

               Counter
               /     \
UnboundedCounter      UpperBoundedCounter

then we have to following:

Both UnbounddedCounter and UpperBoundedCounter can always be upcast to Counter and this requires no explicit cast:

UnboundedCounter uc = new UnboundedCounter();
Counter c = uc;	// no cast, will always work

UpperBoundedCounter ubc = new UpperBoundedCounter(10);
Counter c = ubc;	// no cast, will always work

UnbounddedCounter and UpperBoundedCounter can never be cast to each other
```
UnboundedCounter uc = new UnboundedCounter();
UpperBoundedCounter ubc = uc;		// compiler error
				
```
```
UpperBoundedCounter ubc = new UpperBoundedCounter(10);
UnboundedCounter uc = new ubc;	// compiler error
				
```
- Just because they implement the same interface does not mean they have the same behavior, they may each contain methods the other doesn't and thus, as themselves, exhibit totally different behavior

Counter can be downcast to both UnbounddedCounter and UpperBoundedCounter; however an explicit cast is required as a ClassCastException may occur (if the reference is not to an object of the type being cast to).

Counter c = new UnboundedCounter();
UnboundedCounter uc = (UnboundedCounter)c;	// ok &helip; c referenced an UnboundedCounter object

Counter c = new UnboundedCounter();
UpperBoundedCounter ubc = (UpperBoundedCounter)c;	// ClassCastException; attempting to cast a reference to an UnboundedCounter object to a UpperBounderCounter reference

Enforcement of Behavior: Sortable/Comparable

interface Sortable {
	int compareTo(Sortable other);
}

class SortableInt implements Sortable {
	SortableInt(int i) {this.i = i;}

	public int compareTo(Sortable other) {
		return Integer.compare(i, ((SortableInt)other).i);
	}

	public String toString() {return "SortableInt " + i;}

	private int i;
}

class SortableString implements Sortable {
	SortableString(String s) {this.s = s;}

	public int compareTo(Sortable other) {
		return (s).compareTo(((SortableString)other).s);
	}

	public String toString() {return "SortableString " + s;}


	private String s;
}

import java.util.*;

class Sorter {
	public static void main(String [] args) {
		Random r = new Random(12345);

		SortableInt [] sortableInts = new SortableInt[10];

		for (int i = 0; i < sortableInts.length; i++)
			sortableInts[i] = new SortableInt(r.nextInt(1000));

		System.out.println( "sortableInts (before sort): " + toString(sortableInts));
		sort(sortableInts);
		System.out.println( "sortableInts (after sort): " + toString(sortableInts));
		
		System.out.println();

		SortableString [] sortableStrings = new SortableString[8];

		for (int i = 0; i < sortableStrings.length; i++)
			sortableStrings[i] = new SortableString("Str" + r.nextInt(1000));

		System.out.println( "sortableStrings (before sort): " + toString(sortableStrings));
		sort(sortableStrings);
		System.out.println( "sortableStrings (after sort): " + toString(sortableStrings));
	}


	static String toString(Sortable [] arr) {
		String result = "{";
		for (int i = 0; i < arr.length; i++)
			result += arr[i] + (i < arr.length-1 ? ", " : "");
		return result + "}";
	}

	static void sort(Sortable [] arr) {
		for (int last = arr.length-1; last >= 0; last--)
			for (int i = 0; i < last; i++)
				if (arr[i].compareTo(arr[i+1]) > 0) {
					Sortable temp = arr[i];
					arr[i] = arr[i+1];
					arr[i+1] = temp;
				}
	}
}

The output:

sortableInts (before sort): {SortableInt 251, SortableInt 80, SortableInt 241, SortableInt 828, SortableInt 55, SortableInt 84, SortableInt 375, SortableInt 802, SortableInt 501, SortableInt 389}
sortableInts (after sort): {SortableInt 55, SortableInt 80, SortableInt 84, SortableInt 241, SortableInt 251, SortableInt 375, SortableInt 389, SortableInt 501, SortableInt 802, SortableInt 828}

sortableStrings (before sort): {SortableString Str517, SortableString Str942, SortableString Str390, SortableString Str806, SortableString Str12, SortableString Str384, SortableString Str787, SortableString Str303}
sortableStrings (after sort): {SortableString Str12, SortableString Str303, SortableString Str384, SortableString Str390, SortableString Str517, SortableString Str787, SortableString Str806, SortableString Str942}

Notes

Note the downcasting … we need to get back to the actual class type in order to carry out the comparisons
- Again, all SortableInt objects are Sortable objects as well, but not all Sortable objects are SortableInt objects (some of them could be SortableStrings)
The upcasting occurs when sending the array arguments to doIt
The call to compareTo uses arr[i] as the receiver and arr[i+1] as the argument (sent to parameter other). The parameter is clearly declared in the compareTo method as Sortable; the question is which compareTo method is called? The answer is one of the core properties of object-oriented programming and directly related to our discussion of the hierarchy, up/downcasting, and reference variables vs objects. Recall that references variables and their types are specified at compile-time when they are declared; objects (and their types are created at run time, as a result of new.



Before we leave this example, look at the following variation on Sorter:

import java.util.*;

class Sorter2 {
	public static void main(String [] args) {
		Random r = new Random(12345);

		Sortable [] sortables = new Sortable[10];

		for (int i = 0; i < sortables.length; i++)
			sortables[i] = new SortableInt(r.nextInt(1000));

		System.out.println( "sortables (before sort): " + toString(sortables));
		sort(sortables);
		System.out.println( "sortables (after sort): " + toString(sortables));
		
		System.out.println();
	}


	static String toString(Sortable [] arr) {
		String result = "{";
		for (int i = 0; i < arr.length; i++)
			result += arr[i] + (i < arr.length-1 ? ", " : "");
		return result + "}";
	}

	static void sort(Sortable [] arr) {
		for (int last = arr.length-1; last >= 0; last--)
			for (int i = 0; i < last; i++)
				if (arr[i].compareTo(arr[i+1]) > 0) {
					Sortable temp = arr[i];
					arr[i] = arr[i+1];
					arr[i+1] = temp;
				}
	}
}


One final note: the Sortable interface exists in Java as the Comparable interface and is the basis for allowing 
sorting of classes regardless of their behavior — as long as they implement Comparable 

Interface Inheritance: Collection/List

The Collection Interface

interface Collection {
	boolean add(int value);
	boolean remove(int value);
	int size();
	boolean isEmpty();
}


class Set implements Collection {
	public boolean add(int value) {
		if (find(0, size-1, value) != -1) return false;
		values[size] = value;
		size++;
		return true;
	}

	public boolean remove(int value) {
		int pos = find(0, size-1, value);
		if (pos == -1) return false;
		shiftLeft(pos, size-1);
		size--;
		return true;
	}

	public int size() {return size;}
	public boolean isEmpty() {return size() == 0;}

	public String toString()  {
		String result = "{";
		for (int i = 0; i < size; i++)
			result += values[i] + (i < size-1 ? ", " : "");
		return result + "}";
	}

	private int find(int lo, int hi, int value) {
		if (lo > hi) return -1;
		if (value == values[lo]) return lo;
		return find(lo+1, hi, value);
	}

	private void shiftLeft(int pos, int hi) {
		if (pos > hi) return;
		values[pos] = values[pos+1];
		shiftLeft(pos+1, hi);
	}
	
	private static final int CAPACITY = 100;
	private int [] values = new int[CAPACITY];
	private int size = 0;
}


class Vector implements Collection {
	public boolean add(int value) {
		values[size] = value;
		size++;
		return true;
	}

	public boolean add(int pos, int value) {
		shiftRight(pos, size-1);
		values[pos] = value;
		size++;
		return true;
	}

	public boolean remove(int value) {
		int pos = find(0, size-1, value);
		if (pos == -1) return false;
		shiftLeft(pos, size-1);
		size--;
		return true;
	}

	public int removeAt(int pos) {
		int hold = values[pos];
		shiftLeft(pos, size-1);
		size--;
		return hold;
	}

	public int get(int pos) {
		return values[pos];
	}

	public void set(int pos, int value) {
		values[pos] = value;
	}

	public int size() {return size;}
	public boolean isEmpty() {return size() == 0;}

	public String toString()  {
		String result = "{";
		for (int i = 0; i < size; i++)
			result += values[i] + (i < size-1 ? ", " : "");
		return result + "}";
	}

	private int find(int lo, int hi, int value) {
		if (lo > hi) return -1;
		if (value == values[lo]) return lo;
		return find(lo+1, hi, value);
	}

	private void shiftLeft(int pos, int hi) {
		if (pos > hi) return;
		values[pos] = values[pos+1];
		shiftLeft(pos+1, hi);
	}
	
	private void shiftRight(int pos, int hi) {
		if (hi < pos) return;
		values[hi+1] = values[hi];
		shiftRight(pos, hi-1);
	}
	

	private static final int CAPACITY = 100;
	private int [] values = new int[CAPACITY];
	private int size = 0;
}


import java.util.*;

class CollectionApp {
	public static void main(String [] args) {
		doIt(new Set());
		System.out.println();
		System.out.println();
		doIt(new Vector());
	}

	static void doIt(Collection c) {
		System.out.println("===== " + c.getClass().getName());

		Random r = new Random(12345);

		System.out.println("--- Adding");
		for (int i = 0; i < 20; i++) {
			int num = r.nextInt(10);
			System.out.println(num + " -> " + c.add(num) + " " + c);
		}

		System.out.println();

		System.out.println("--- Removing");
		while (!c.isEmpty()) {
			int num = r.nextInt(10);
			System.out.println(num + " -> " + c.remove(num) + " " + c);
		}
	}
}


The List Interface

interface List extends Collection {
	int get(int index);
	void set(int index, int value);
	boolean add(int index, int value);
	int removeAt(int index);
}


class Vector implements List {
	…
}


import java.util.*;

class ListApp {
	public static void main(String [] args) {
		doIt(new Vector());
	}

	static void doIt(List l) {
		System.out.println("===== " + l.getClass().getName());
		System.out.println();
		System.out.println("Calling CollectionApp.doIt");
		CollectionApp.doIt(l);

		System.out.println();
		System.out.println();
		System.out.println("Perfoming ListApp.doIt");
		Random r = new Random(12345);

		System.out.println("--- Indexed Adding");
		for (int i = 0; i < 20; i++) {
			int pos = r.nextInt(l.size()+1);
			int num = r.nextInt(10);
			System.out.println(num + " @" + pos  + " -> " + l.add(pos, num) + " " + l);
		}

		System.out.println();

		System.out.println("--- Getting");
		for (int i = 0; i < l.size(); i++) 
			System.out.println("@" + i + " -> " + l.get(i));
	

		System.out.println();

		System.out.println("--- Setting");
		for (int i = 0; i < l.size(); i++) {
			int num = r.nextInt(10);
			l.set(i, num);
			System.out.println(num + " @" + i  + " -> " + l);
		}

		System.out.println();

		System.out.println("--- Indexed Removing");
		while (!l.isEmpty()) {
			int pos = r.nextInt(l.size());
			System.out.println("@" + pos + " -> " + l.removeAt(pos) + " " + l);
		}
	}
}






Classes can implement multiple interfaces (just like someone could be a doctor and a lawyer and an EMT, etc … wearing different hats).

Files used in this Lecture

CISC 3115
Modern Programming Techniques
Lecture 6
Interfaces

Interfaces: Overview

General Usage

Computing

In Object-Oriented Programming (OOP)

In Java

Change of Representation: Social Security Number

Modelling Social Security Numbers

Specification of Behavior

Choosing the Internal Representation

Coding a Demo App for our Class

A Change of Implementation (Representation)

The Demo App Remains Unchanged

Some Issues

Interfaces

Implementations of the Interface

The Apps

Programming to the Interface

Revisiting our Apps

Change of Functionality: Counter

Enforcement of Behavior: Sortable/Comparable

Interface Inheritance: Collection/List

The `Collection` Interface

The `List` Interface

Files used in this Lecture

CISC 3115 Modern Programming Techniques Lecture 6 Interfaces

Interfaces: Overview

General Usage

Computing

In Object-Oriented Programming (OOP)

In Java

Change of Representation: Social Security Number

Modelling Social Security Numbers

Specification of Behavior

Choosing the Internal Representation

Coding a Demo App for our Class

A Change of Implementation (Representation)

The Demo App Remains Unchanged

Some Issues

Interfaces

Implementations of the Interface

The Apps

Programming to the Interface

Revisiting our Apps

Change of Functionality: Counter

Enforcement of Behavior: Sortable/Comparable

Interface Inheritance: Collection/List

The Collection Interface

The List Interface

Files used in this Lecture

CISC 3115
Modern Programming Techniques
Lecture 6
Interfaces

The `Collection` Interface

The `List` Interface