Composition इतर ऑब्जेक्ट्स धारण करून ("has-a" संबंध) आणि त्यांना डेलिगेट करून वर्तन तयार करते. Inheritance क्लास विस्तारित करून ("is-a") वर्तन प्राप्त करते. "कंपोजिशन अधिक का बढावा दा" ही सल्ला अस्तित्वात आहे कारण इनहेरिटन्स बेस क्लासला घट्ट, कमजोर कपलिंग तयार करते, तर कंपोजिशन लवचिक राहते.
<T> <T> {
{ add(x); }
T { remove(size() - ); }
}
class Stack<T> {
private final List<T> items = new ArrayList<>(); // HAS-A list
void push(T x) { items.add(x); }
T pop() { return items.remove(items.size() - 1); }
// only push/pop are exposed → LIFO invariant is safe
}
असणे ऐवजी सूची धारण करून, Stack केवळ हवेत्या ऑपरेशन्स उघड करते.
| Composition | Inheritance |
|---|---|
| लवचिक, runtime वर भाग बदलू शकता | कंपाईल वेळी निश्चित |
| आंतरिक लपवते (डेलिगेशन) | संपूर्ण इंटरफेस इनहेरिट करते |
| अधिक वायरिंग/बॉयलरप्लेट | सत्य is-a असताना कमी कोड |
| नाजुक बेस क्लास टाळते | बेस बदलल्यास सबक्लास तुटतो |
इनहेरिटन्स फक्त खऱ्या, स्थिर is-a संबंधांसाठी वापरा; कंपोजिशन "मला हे वर्तन हवे" साठी वापरा.
इनहेरिटन्स पेरेंट्सचे संपूर्ण इंटरफेस उघड करते, त्यामुळे सबक्लास स्वतःचे करार पूर्णपणे नियंत्रित करू शकत नाही — Stack extends ArrayList गळती हा क्लासिक उदाहरण आहे.
कंपोजिशन संबंध स्पष्ट आणि अदलाबदल करण्यायोग्य ठेवते, म्हणूनच डिपेंडेंसी इंजेक्शन, स्ट्रॅटेजी पॅटर्न आणि बहुतेक लवचिक डिজाइन यावर अवलंबून आहेत.