This article is more than 1 year old

First among equals

The contract metaphor is an effective way of approaching API design

Interface is not implementation

The contract for C#'s Object.Equals is similar to the corresponding Java contract. It clarifies more clearly that exceptions should not be thrown as a result of equality comparison and makes some qualifications concerning floating-point number comparison.

However, the most obvious shortcoming is not so much in the content of the contract as in its context: it is considered under the heading "Notes to Implementers". Whilst it is certainly true that the contract binds and guides an implementation, that is only one half of the contractual relationship. A contract is not just the view from the supplier: it also describes what the client can rely on. A contract is therefore more than just an implementation guideline: it is part of the interface.

Contracts form the basis of substitutability: an implementation can be said to satisfy the contract described by an interface, so any implementation satisfying that contract can be substituted wherever that interface is expected. It is why class hierarchies should follow a notion of substitutability — a strong form of the "is a" or "is a kind of" view of inheritance — before any commonality of implementation through inheritance is considered. A subclass follows and specialises the contract of its parents. This notion of substitutability, known as the Liskov Substitution Principle [6], can be derived from the contract model.

As an aside, it can be considered ironic that Eiffel [2], the language that has done the most to promote and embody the concept of contracts, using pre- and postconditions, actually fails the Liskov criteria for its own class-based type system.

Good relations

There is another way to test equality between objects: relational comparison. Two objects can be considered equal if they compare neither greater nor less than one another.

In Java the Comparable interface provides the standard protocol for querying the relation between two objects defined to have a natural ordering. There is only one method, compareTo, and this uses strcmp semantics, so called because of the standard string comparison function in C that uses the same result model: a negative value if the left-hand side of the comparison compares less than the right-hand side; zero if they are considered equal; a positive value if the left-hand side compares greater than the right-hand side.

Assuming that sgn returns the value -1, 0 or +1 when its operand is less than, equal to or greater than zero, respectively, the Comparable contract can be stated as follows:

antisymmetric:
sgn(a.compareTo(b)) == -sgn(b.compareTo(a))
transitive:
sgn(a.compareTo(b)) == s && sgn(b.compareTo(c)) == s implies sgn(a.compareTo(c)) == s
consistent equivalence:
a.compareTo(b) == 0 implies sgn(a.compareTo(c)) == sgn(b.compareTo(c)) for all c
consistent:
a.compareTo(b) returns the same as long as a and b are unmodified
null incomparability:
a.compareTo(null) throws a NullPointerException
incompatible type incomparability:
a.compareTo(b) throws a ClassCastException if the types of a and b cannot be meaningfully compared
incompatible type symmetry:
a.compareTo(b) throws a ClassCastException if and only if b.compareTo(a) throws a ClassCastException

There is no strict requirement that a.compareTo(a) == 0 has the same result as a.equals(b), although it is strongly recommended.

The contract for IComparable.CompareTo in C# is similar but has a couple of notable differences: there is a requirement to be reflexive and any object compares greater than null instead of throwing an exception.

In common with strcmp and other similarly specified operations, note that the contracts are not defined in terms of -1, 0 and +1 return values, which sometimes programmers mistakenly assume to be the case. It is OK to implement ordering functions to return -1, 0 and +1, because these certainly satisfy the contractual requirement for returning less than, equal to and greater than zero, but it is not OK for a caller to rely on these specific values.

For example, imagine a Date class whose representation is scalar, counting the number of days since a given epoch [7]:

public final class Date implements Comparable
{    ...
    public int compareTo(Object other)
    {
        return day - ((Date) other).day;
    }
    private int day;
}

More about

TIP US OFF

Send us news


Other stories you might like