CISC 3115
Modern Programming Techniques
Lecture 6
Interfaces
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, 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()).
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() {…}
…
}
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;
}
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;
}
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 an asInt method in our StringSSNum
implementation:
int asInt() {…}
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.
A possibly better example might be various Container classe: tatic fixed-sized, dynamic fixes-sized and growableo, and methods
to return their capacities: the growable really does not need any such method (the capacity changes as needed), the first will always return the same value;
it's only the dynamic fixed that truly calls for a getCapacity method.
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, if not in this course, then at least in 3130.
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., we say an object of the implementation class is-a object of the interface type as well, and can appear in any context
a reference variable of the interface type may appear.
Here is an interface for our social security number:
interface SSNum {
int getArea();
int getGroup();
int getSerial();
}
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 above two classes are each said to be an implementing class or simply implementation of the interface
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());
}
}
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-aSSNum 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"));
}
}
Other Examples of Using Interfaces to Maintain Consistency When Changing the Representation
Java's Collections (ArrayList vs LinkedList)
Money (dollars/cents vs cents)
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(); //---------
}
}
Both the UnboundedCounter as well as the UpperBoundedCounter
can be sent as arguments to the Counter parameter of doIt
because they both implement the Counter interface and the thus considered
Counter objects
We say that UnboundedCounteris-aCounter
(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:
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.
Hierarchies of Interfaces/Classes and Up/Downcasting
If we view the above three types (the interface and two implementing classes) as a hierarchy:
Counter
/ \
UnboundedCounter UpperBoundedCounter
then we have to following:
Both UnboundedCounter 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
UnboundedCounter and UpperBoundedCounter can never be cast to each other
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 UnboundedCounter 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(); // this is an upcast!
UnboundedCounter uc = (UnboundedCounter)c; // ok &helip; c referenced an UnboundedCounter object
Counter c = new UnboundedCounter(); // this is an upcast!
UpperBoundedCounter ubc = (UpperBoundedCounter)c; // ClassCastException; attempting to cast a reference to an UnboundedCounter object to a UpperBounderCounter reference
Other Examples of Using Interfaces to Maintain Consistency When Changing the Functionality
Java's Collections (Lists vs Sets)
Sorts (bubble vs selection)
Specification/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;
}
}
}
Note the downcasting … we need to get back to the actual class type in order to carry out the comparison using the method of the class of the actual object
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
class Set implements Collection {
public boolean add(int value) {
if (find(value) != -1) return false;
values[size] = value;
size++;
return true;
}
public boolean remove(int value) {
int pos = find(value);
if (pos == -1) return false;
shiftLeft(pos);
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 value) {
for (int i = 0; i < size; i++)
if (values[i] == value) return i;
return -1;
}
private void shiftLeft(int pos) {
for (int i = pos; i < size-1; i++)
values[i] = values[i+1];
}
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);
values[pos] = value;
size++;
return true;
}
public boolean remove(int value) {
int pos = find(value);
if (pos == -1) return false;
shiftLeft(pos);
size--;
return true;
}
public int removeAt(int pos) {
int hold = values[pos];
shiftLeft(pos);
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 value) {
for (int i = 0; i < size; i++)
if (values[i] == value) return i;
return -1;
}
private void shiftLeft(int pos) {
for (int i = pos; i < size-1; i++)
values[i] = values[i+1];
}
private void shiftRight(int pos) {
for (int i = size; i > pos; i--)
values[i] = values[i-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);
}
}
}
