Liskov Substitution Principle (LSP) ले भन्छ कि subtype को objects तिनीहरूको base type को लागि substitutable हुनु पर्छ प्रोग्रामको सही होस् विनष्ट नगरी। यदि कोड 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 ले कल गरिसकेकोहरूले भरोसा गरेको अनुबन्ध तोड्छ: width र height लाई स्वतन्त्र रूपमा सेट गर्न। यो "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 को formal कोर।
इन्हेरिट्यान्स छोड्नुहोस्: Square र Rectangle दुवै Shape हुन् एक area() को साथ, तर न एक अर्को हो। व्यवहार मडेल गर्नुहोस्, भोली वर्गीकरण होइन।
LSP भनेको polymorphism को सुरक्षित बनाउन हो: यो बिना, प्रत्येक if (x instanceof Square) जाँच फिर्ता आउछ, subtyping को बिन्दु को पराजय गरिरहेको छ।
यो inheritance डिजाइनलाई व्यावहारिक अनुबन्ध वरिपरि फिर्ता फ्रेम गर्छ, शब्दावली होइन — "composition लाई पक्ष गर्नुहोस्" को वास्तविक कारण यो हो कि धेरै is-a सम्बन्ध खामोसीसाथ LSP को उल्लङ्घन गर्छन्।
विस्तृत उत्तरसहित IT अन्तर्वार्ता प्रश्नहरूको पुस्तकालय — जुनियरदेखि सिनियरसम्म।
दान गर्नुहोस्