"Ha viszont elvárod, hogy ha adott állapotban, adott argumentumokkal a leszármazott osztályok pontosan ugyanazt adják vissza, akkor pl. az összes hashCode() alapú collection-t bukod, mivel mindegyiknek az Object#hashCode-ot kellene visszaadnia."
Nem, nem ugyanazt kell visszaadnia, hanem be kell tartania a szemantikát. És le is van írva, hogy a hashCode-nak mi a szemantikája: nem várja el, hogy az Object.hashCode() értékével kell megyegyezzen, hanem
"Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer, provided no information used in equals comparisons on the object is modified. This integer need not remain consistent from one execution of an application to another execution of the same application.
•If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result. "
Ennyi. És erre a contractra írhatok én unit testet, használhatom, és minden conform hashCode() implementációval működni fog az összes tesztem.
Az persze lehet, hogy egy unit testet valójában nem erre a contractra írsz meg, hanem használsz olyan feltételezéseket, ami nincs benne ebben a contractban, például kikötheted a tesztben, hogy egyezzen meg bármelyik hashCode() az Object.hashCode()-dal, de ez sehol nincs leírva a contractban.
"hozzárendelésre pontosan kell egyezniük vagy a contractben vállaltaknak megfelelően kell működniük?"
Ha a contract definiálja, hogy hogyan kell kinéznie a kimenetnek bitre pontosan, akkor igen, pontosan meg kell egyeznie a hozzárendelésnek.
Például nem tudsz kétféle koszinuszfüggvény implementációt úgy csinálni, hogy ne egyezzen meg a kimenet. Mert ha két cos implementáció (például egy CPU-only meg egy FPU-only) ugyanazt kell, hogy visszaadja mindig. Nem lehet más, mert akkor bugos: nem felel meg a specifikációnak.
Ha egy EmailValidator.isValid() specifikációja csak annyi, hogy "Validálja az e-mail címet" akkor az egy gagyi specifikáció: készíthetsz olyan implementációkat, amelyek ugyanarra az inputra teljesen máshogy viselkednek a hívó szempontjából. És ez rossz, mert nem felcserélhetőek az implementációk - akkor meg minek az interfész? Nem testesít meg semmit valójában.
Ha mondjuk az a specifikációja, hogy "RFC822 szerinti validációt készít", akkor minden EmailValidator implementációnak RFC822 szerinti validációt kell készítenie.
Vagy hogy egy ténylegesen kézzelfogható példát mondjak:
Ha mondjuk egyik napon a hálózati áram 230 V helyett 450 V lenne, akkor hiába ugyanaz a csatlakozó és az aljzat (azaz formailag ugyanaz az interfész), szemantikailag nem ugyanolyan: bedugsz egy 230 V-ra méretezett eszközt és megsül.
Az, hogy egy interfész formailag nem változik, attól még lehet inkompatibilis változás az API-ban: az API nem csak formaiság, szemantikája is van.