Mislim da nema nekog generalnog pravila ali, kao sto kazu mnoge knjizice, treba preferirati kompoziciju.
Odlican primer gde kompozicija potpomaze dizajn je Bridge design pattern koji koristi kompoziciju da bi 'razbio' eksponencijalnu eksploziju klasa.
Jedan od primera za to je da ako imas kontrole u aplikaciji, npr. baznu klasu Widget i iz nje izvedene PushButton, Label, CheckBox i ako zelis da ti app radi na razlicitim sistemima (Windows, Linux, Mac) onda bi morao da imas drugaciji kod za iscrtavanje. Jedna od ideja je da, ako posmatramo Label, imas LabelWin, LabelLinux, LabelMac izvedene iz Label. Isto bi tako iz svih klasa koji predstavljaju konkretne widgete nasledjivao po 3 klase. Eksponencijalna eksplozija se da primetiti kada sad trebas da dodas novi Widget ili novi sistem (Netware npr.)...
Bridge pattern onda koristi kompoziciju tako sto izdvaja hijerarhiju widgeta sa jedne strane i hijerarhiju operativnih sistema (bazna klasa Platform i iz nje izvedene Windows, Mac i Linux). Widget SADRZI pointer na Platform instancu u zavisnosti na kojem smo sistemu i poziva metode platform instance za iscrtavanje.
Detaljnije o ovome mozes anci na netu...
Iz mog nekog iskustva, prvi nagovestaj koriscenja kompozicije je situacija kada ti zatreba visestruko nasledjivanje. Npr. ako imas objekte u igri, neki od njih su Renderable a neki nisu, na neke se apply-uje kolizija a na neke ne, onda bi mogli da izdvojimo one koji su i Renderable i Collidable. Npr. neka to bude klasa Actor. Logicno bi bilo da se nasledi iz Renderable i Collidable. Razlika izmedju nasledjivanja i kompozicije je u tome sto je, mozda vec i znas, nasledjena klasa 'is' Renderable a kod kompozicije 'has' Renderable. Po meni je ovde bolje imati kompoziciju, pointer na Renderable i na Collidable i onda inicijalizujes obe instance u zavisnosti da li ce objekat imati osobine da moze da se iscrtava i da li ce da ucestvuje u koliziji (npr. Background je renderable ali nije collidable, triggeri neki na mapi su collidable ali nisu renderable). Jeste kontradiktorno to sto je objekat Renderable i Collidable 'is' -> nasledjivanje, suprotno tome da sadrzi Renderable i Collidable u sebi ali ti kompozicija u ovom slucaju cak daje mogucnost da u runtime podesavas i menjas Renderable i Collidable osobine (objekat postane duh u igri u jednom trenutku npr. :) i samo odradis delete m_pCollidable ).
Potpis
EOF
