Η Αρχή Αντικατάστασης Liskov (LSP) δηλώνει ότι αντικείμενα ενός υποτύπου πρέπει να είναι αντικαταστάσιμα για τον βασικό τους τύπο χωρίς να σπάσουν την ορθότητα του προγράμματος. Αν ο κώδικας λειτουργεί με έναν Base, πρέπει να λειτουργεί με οποιοδήποτε Subclass — ίδιες συμπεριφορικές προσδοκίες, καμία έκπληξη.
class Rectangle {
protected int w, h;
void setWidth(int w) { this.w = w; }
void setHeight(int h) { this.h = h; }
int area() { return w * h; }
}
class Square extends Rectangle { // "a square IS-A rectangle"... seemingly
void setWidth(int w) { this.w = w; this.h = w; } // keep sides equal
void setHeight(int h) { this.w = h; this.h = h; }
}
void resize(Rectangle r) {
r.setWidth(5);
r.setHeight(4);
assert r.area() == 20; // holds for Rectangle... FAILS for Square (area=16)
}
Το Square παραβιάζει το συμβόλαιο που στηρίζονται οι κάλεσαντες: το ανεξάρτητο ορισμό του πλάτους και του ύψους. Περνά το δοκιμάσιο "is-a" αλλά παραβιάζει το LSP.
A subtype must NOT:
✗ strengthen preconditions (demand more than the base, e.g. reject valid inputs)
✗ weaken postconditions (promise less than the base)
✗ break invariants the base guarantees
✗ throw new unexpected exceptions for previously valid calls
A subtype MAY:
✓ weaken preconditions (accept more) ✓ strengthen postconditions (promise more)
Αυτή είναι αντιμεταβολή εισόδων, συμμεταβολή εξόδων — ο τυπικός πυρήνας του LSP.
Απορρίψτε την κληρονομικότητα: το Square και το Rectangle είναι και τα δύο Shapes με μια area(), αλλά κανένα δεν είναι το άλλο. Μοντελοποιήστε τη συμπεριφορά, όχι αφελή ταξινομία.
Το LSP είναι αυτό που κάνει τον πολυμορφισμό ασφαλή: χωρίς αυτό, κάθε έλεγχος if (x instanceof Square) σέρνεται πάλι, αναιρώντας το σημείο της υποτύπωσης.
Επαναπροσδιορίζει το σχεδιασμό κληρονομικότητας γύρω από συμπεριφορικά συμβόλαια, όχι λεξιλόγιο — ο πραγματικός λόγος που υπάρχει το "favor composition" είναι ότι πολλές σχέσεις is-a σιωπηλά παραβιάζουν το LSP.