Interface Contract, Class Object?

Question

Is contract to interface as object is to class?

What is the need to differentiate identical things like this, from the code to the executing code? I sort of get the idea behind naming a class a class and the instantiated executing class an object, but overall, is that the only reason for these semi-redundant terms?

Answer 1

Not really. There are four terms here, so I'll go over each of them:

Interface

An interface is an abstract class (in languages like Java where there is no multiple inheritance, sometimes there are other restrictions, such as a separate data type) that is intended to be used as a common base to access a number of similarly-behaving objects. Conceptually, there is no requirement for abstractness, but usually, an interface will have at least one abstract method. An interface is a method for your program to communicate with a number of similar classes, each with different semantics but the same general purpose.

Contract

A contract is the implicit agreement you make between users and implementers of a class or interface. For instance, preconditions and postconditions (invariants are usually a contract within the class' implementation - generally, things like the relation between internal members don't need to be exposed). The specification for a return value or an argument can also be part of the contract. It basically represents how to use the function/class/interface, and isn't generally fully representable in any language (some languages, like Eiffel, allow you to put explicit contracts in, but even these can't always fully flesh out the requirements). When you implement an interface or derive from a class, you are always having to meet the interface requirements, or, when overriding a non-abstract class, to behave similar enough that an external viewer doesn't notice the difference (this is the Liskov Substitution Principle; a derived object should be capable of replacing the base with no difference in behavior from the outside perspective).

Class

A class doesn't need a lot of going over, since you clearly have used them before. A class is the data type, and in some languages is a superset of interfaces (which have no formal definition, as in C++), and in others is independent (such as in Java).

Object

An object is an instance of a class type (or of any non-class type, usually). The exact definition of an object is very specific to a language, but the general definition is the actual thing referred to by multiple references/pointers to the same thing - for instance, in some languages like Java, == compares whether two variables are the same object, not necessarily whether they are semantically the same. Objects are independent from classes or interfaces - they represent a single instance. Another way of thinking of it is that class or interface is the mold, and the object is the physical object that comes out of the mold (a rather bad analogy, but it's the best I can come up with right now).

Answer 2

No, not really. A class is a template that you define. Each object that instantiates that class follows the template. They're not really redundant terms, because the two things are not identical. You can think of a class as a user-defined data type. Classes and objects are different from each other in the exact same way that the primitive data type int is different from the literal value 3.

An interface defines a set of methods that all implementing classes must support. The interface itself is the contract that you define for the implementing classes. It just says that any class that implements the interface, must have that interface's set of public methods.