का संबंध है — जिसे से मॉडल किया जाता है (एक )। का संबंध है — जिसे से मॉडल किया जाता है (एक के पास है)। सही वाला चुनना एक मूलभूत मॉडलिंग निर्णय है।
का संबंध है — जिसे से मॉडल किया जाता है (एक )। का संबंध है — जिसे से मॉडल किया जाता है (एक के पास है)। सही वाला चुनना एक मूलभूत मॉडलिंग निर्णय है।
CarVehicleCarEngine// IS-A → inheritance
class Vehicle { void move() {} }
class Car extends Vehicle { } // a Car IS A Vehicle
// HAS-A → composition
class Engine { void start() {} }
class Car2 {
private Engine engine = new Engine(); // a Car HAS AN Engine
void start() { engine.start(); } // delegate to the part
}
पूछें: "क्या X, Y का एक प्रकार है, या X के पास Y है/उसका उपयोग करता है?"
A Dog IS-A Animal → inheritance ✅
A Car HAS-A Engine → composition ✅
A Square IS-A Shape → inheritance ✅
A Manager HAS Employees → composition (a list) ✅
A Stack HAS-A list (not IS-A) → composition (see earlier pitfall) ✅
लोग code का पुन: उपयोग करने के लिए inheritance की ओर बढ़ते हैं, तब भी जब संबंध वास्तव में has-a होता है। अगर आप subclass को हर जगह base के स्थान पर कभी प्रतिस्थापित नहीं करते, तो यह शायद is-a नहीं है — composition का उपयोग करें।
यह भेद "inheritance के बजाय composition को प्राथमिकता दें" के पीछे का व्यावहारिक निर्णय नियम है: वह संबंध चुनें जो सच हो, वह नहीं जो कुछ lines बचाए।
इसे सही करने से hierarchies उथली और ईमानदार रहती हैं, और यह Liskov उल्लंघनों को रोकता है जहां एक "subtype" वास्तव में अपने parent के स्थान पर खड़ा नहीं हो सकता।