Liskov Substitution Principle (LSP) کہتا ہے کہ ایک subtype کے objects اپنے base type کی جگہ استعمال ہو سکتے ہیں پروگرام کی درستگی کو نقصان پہنچائے بغیر۔ اگر کوڈ Base کے ساتھ کام کرتا ہے، تو یہ کسی بھی Subclass کے ساتھ کام کرنا چاہیے — ایک جیسی behavioral توقعات، کوئی حیرانی نہیں۔
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 معاہدے کو توڑتا ہے جس پر callers انحصار کرتے ہیں: width اور height کو آزادانہ طور پر set کرنا۔ یہ "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)
یہ inputs کا contravariance، outputs کا covariance ہے — LSP کا رسمی بنیادی حصہ۔
Inheritance کو ختم کریں: Square اور Rectangle دونوں Shapes ہیں جن کے پاس area() ہے، لیکن ایک دوسرے سے نہیں۔ رویے کو ماڈل کریں، سادہ لوحانہ taxonomy کو نہیں۔
LSP وہ چیز ہے جو polymorphism کو محفوظ بناتی ہے: اس کے بغیر، ہر if (x instanceof Square) چیک واپس آتی ہے، subtyping کی نقطہ نظر کو شکست دیتی ہے۔
یہ inheritance کے ڈیزائن کو behavioral contracts کے ارد گرد دوبارہ تشکیل دیتا ہے، صرف لغت نہیں — "composition کو ترجیح دیں" کا اصل سبب یہ ہے کہ بہت سے is-a relationships خاموشی سے LSP کی خلاف ورزی کرتے ہیں۔
تفصیلی جوابات کے ساتھ IT انٹرویو سوالات کی ایک لائبریری — جونیئر سے سینئر تک۔
عطیہ دیں