Liskov Substitution Principle (LSP) phát biểu rằng các object của một subtype phải có thể thay thế cho base type của chúng mà không phá vỡ tính đúng đắn của chương trình. Nếu code làm việc với một Base, nó phải làm việc được với bất kỳ Subclass nào — cùng kỳ vọng về hành vi, không bất ngờ.
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 { // "một square LÀ MỘT rectangle"... có vẻ vậy
void setWidth(int w) { this.w = w; this.h = w; } // giữ các cạnh bằng nhau
void setHeight(int h) { this.w = h; this.h = h; }
}
void resize(Rectangle r) {
r.setWidth(5);
r.setHeight(4);
assert r.area() == 20; // đúng với Rectangle... THẤT BẠI với Square (area=16)
}
Square phá vỡ hợp đồng mà bên gọi dựa vào: đặt width và height độc lập. Nó vượt qua phép thử "is-a" theo nghĩa tiếng Anh nhưng vi phạm LSP.
Một subtype KHÔNG ĐƯỢC:
✗ làm mạnh thêm tiền điều kiện (precondition) (đòi hỏi nhiều hơn base, ví dụ từ chối input hợp lệ)
✗ làm yếu đi hậu điều kiện (postcondition) (hứa hẹn ít hơn base)
✗ phá vỡ các bất biến mà base đảm bảo
✗ ném exception mới bất ngờ cho các lời gọi trước đó vẫn hợp lệ
Một subtype CÓ THỂ:
✓ làm yếu tiền điều kiện (chấp nhận nhiều hơn) ✓ làm mạnh hậu điều kiện (hứa hẹn nhiều hơn)
Đây là tính phản biến (contravariance) của input, tính đồng biến (covariance) của output — phần lõi hình thức của LSP.
Bỏ inheritance: Square và Rectangle đều là các Shape có một area(), nhưng không cái nào là cái kia. Hãy mô hình hóa hành vi, không phải phân loại ngây thơ.
LSP là thứ khiến polymorphism an toàn: không có nó, mọi kiểm tra if (x instanceof Square) lại len lỏi quay về, làm vô nghĩa điểm mấu chốt của subtyping.
Nó định hình lại thiết kế inheritance xoay quanh các hợp đồng hành vi, không phải từ vựng — lý do thực sự của "ưu tiên composition" là nhiều quan hệ is-a âm thầm vi phạm LSP.