Egy picit naivnak éreztem ezt a blogbejegyzést, de a vége felé már kezdte picit a felszínt kapirgálni. Az kompozíció egy erőteljesebb eszköz, mint az öröklődés, sok esetben simán kiváltható az öröklődés kompozícióval, és az eredmény általában flexibilisebb, hatékonyabb objektum hierarchia lesz.
A legegyszerűbb előnyt a tervezési minták egy csportja (pl. strategy, decorator) elég jól megmutatja, hogy ha csak öröklődést használunk, akkor könnyen egy szétburjánzó, nagy létszámú osztály hierarchiját kapunk, ami kiküszöbölhető kompozíció használatával.
Az öröklődés szorosabb kötődést fog eredményezni az egyes komponensek között, mint a kompozíció, főleg hogy általában kompozíció esetén a kapcsolat egy interfészen keresztül jól definiálható. Utóbbi esetben az adott komponens egyszerűen lecserélhető egy másik megvalósításra (pl. gyorsabb rendezésre/keresésre van szükségünk), míg öröklődés esetén ez nem mondható el.
Az előbbi pont kiteljesedése a dependency injection, ami már PHP-ba is kezd beszűrődni. De egy nagyon egyszerű praktikus hozadéka is van, egy kmpozíción alapuló kódhoz sokkal könnyebb tesztkódot írni, könnyebb mock objecteket (egy adott objektum működését imitáló objektumot) használni. Ugyanezt öröklődésen alapuló kód esetén nem nagyon tudjuk megcsinálni (vagy csak komolyabb hack és peremfeltételek esetén).
Szóval az objektum kompozíció az OOP fejlesztés egy tudatosabb formája, továbblépés az öröklődéshez képest. Szerintem érdemes foglalkozni a témával (göröngyösebb talaj), nem mondanám még, hogy biztosan uralom ezt a terepet, de jobb, felxibilisebb kódot eredményez, ha ebbe az irányba próbálunk meg elmenni, igaz több tudatosságot igényel.
pár gondolat még
A legegyszerűbb előnyt a tervezési minták egy csportja (pl. strategy, decorator) elég jól megmutatja, hogy ha csak öröklődést használunk, akkor könnyen egy szétburjánzó, nagy létszámú osztály hierarchiját kapunk, ami kiküszöbölhető kompozíció használatával.
Az öröklődés szorosabb kötődést fog eredményezni az egyes komponensek között, mint a kompozíció, főleg hogy általában kompozíció esetén a kapcsolat egy interfészen keresztül jól definiálható. Utóbbi esetben az adott komponens egyszerűen lecserélhető egy másik megvalósításra (pl. gyorsabb rendezésre/keresésre van szükségünk), míg öröklődés esetén ez nem mondható el.
Az előbbi pont kiteljesedése a dependency injection, ami már PHP-ba is kezd beszűrődni. De egy nagyon egyszerű praktikus hozadéka is van, egy kmpozíción alapuló kódhoz sokkal könnyebb tesztkódot írni, könnyebb mock objecteket (egy adott objektum működését imitáló objektumot) használni. Ugyanezt öröklődésen alapuló kód esetén nem nagyon tudjuk megcsinálni (vagy csak komolyabb hack és peremfeltételek esetén).
Szóval az objektum kompozíció az OOP fejlesztés egy tudatosabb formája, továbblépés az öröklődéshez képest. Szerintem érdemes foglalkozni a témával (göröngyösebb talaj), nem mondanám még, hogy biztosan uralom ezt a terepet, de jobb, felxibilisebb kódot eredményez, ha ebbe az irányba próbálunk meg elmenni, igaz több tudatosságot igényel.
Üdv,
Felhő
off