What does “contract” of a class mean

Question

I am reading the book The Java Programming Language. In the chapter which explains overriding method, it says:

Making an override met

Answer 1

The contract of a class or interface, in Java or any other OO language, generally refers to the publicly exposed methods (or functions) and properties (or fields or attributes) of that class interface along with any comments or documentation that apply to those public methods and properties.

In the case of the relationship between a class and subclass, any protected methods or properties would be considered "publicly exposed," in the sense that they are exposed to the subclass.

Answer 2

A class's "Contract" is it's public interface or at least the interface if presents to classes other than itself.

This means that it includes any elements (methods, fields, constructors, etc.) that other classes can use.

Answer 3

It's an expression that comes from the idea of contracts in the "real world."

Basically, if you break your contract with a class, then it's not required to behave the way you might expect. From the other direction, it's a promise by the class that if you follow the rules it sets out, it will behave the way its API says.

One common example of a contract in Java is overriding equals() when hashCode() is overridden. Two objects that are considered equal must, by contract, have the same hash code. It's possible to write code that's syntactically correct that doesn't obey this, but it might not work properly, and that's the fault of the programmer who broke the contract.

Answer 4

Contract of type (class, interface, enum) is the, well, the contract this type promises to comply to. It states:

• what are acceptable parameters to constructor and/or methods of this type;
• what you should and/or should not expect this type to be doing. For example, it may state that you shall expect this class to be thread-safe or not thread-safe;
• what are invariants supported by this type. For example, type method addData(float) of MathAverage class which calculates average of it's input may state that every time your call to add(float) is return, you shall expect call to MathAverage.getAverage() to return correct average of current input.
• generally speaking, your type can specify any constraint all it's subtypes must follow. For example, it may say "no method of this type must take longer than 1 second to execute".

Contract is specified in free-form in javadoc of type. There are some tools/practices to enforce execution of contracts, but they are limited, exactly because contract can be arbitrary, or, even, self-contradictory, in case of programmer's error.

Since subtyping(subclassing) can extend/modify behavior of supertype methods in arbitrary way, it may, as well, violate some parts of supertype's contract. Example of this would be extending HashMap, which accepts null values and keys, with some implementation which prohibits null values in calls to it's methods.

Other important aspect about type contract is that subtype can have stronger contract (covering subset of constraints in type's contract), but can't have weaker contract (covering superset of constraints in type's contract). For example, if your type's method 'doX(n)' promises to take O(n) (linear) time, 'doX(n)' in subtype can take O(1) (constant) time, but can not take O(n^2) time.

Answer 5

in simple terms it means you would break the conditions of superclass if u make override code less accesible

Answer 6

A contract in in a Java class is similar to a contract in the real world - In non-technical terms:

It's an agreement that the class will expose certain methods, certain properties, and certain behaviors.

More technical, from here: (bold added by me)

Wouldn't it be nice if all Java classes that you use, including your own, lived up to their promises? In fact, wouldn't it be nice if you actually knew exactly what a given class promises? If you agree, read on [...]

Design by Contract

The Design by Contract (DBC) software development technique ensures high-quality software by guaranteeing that every component of a system lives up to its expectations. As a developer using DBC, you specify component contracts as part of the component's interface. The contract specifies what that component expects of clients and what clients can expect of it.