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
impliessgn(a.compareTo(c)) == s
- consistent equivalence:
a.compareTo(b) == 0
impliessgn(a.compareTo(c)) == sgn(b.compareTo(c))
for allc
- consistent:
a.compareTo(b)
returns the same as long asa
andb
are unmodifiednull
incomparability:a.compareTo(null)
throws aNullPointerException
- incompatible type incomparability:
a.compareTo(b)
throws aClassCastException
if the types ofa
andb
cannot be meaningfully compared- incompatible type symmetry:
a.compareTo(b)
throws aClassCastException
if and only ifb.compareTo(a)
throws aClassCastException
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; }