Az egész nagyobb, mint a részek összege
-Aristotelész
Az idézet Arisztotelésznek tulajdonítható. Alapvetően a szinergiáról van szó. Stephen Covey The 7 Habits of Highly Effective People (A rendkívül hatékony emberek 7 szokása) című bestsellerében a hatodik szokás a szinergizálás. Ami igaz a szervezetekre, az igaz az informatikában is. Egy tárgy teste értékesebb, mint az egyedei. Az informatikában a kompozíció kifejezést használjuk.
Kompozíció
Mit értünk tehát kompozíció alatt? “A kompozíció az objektumorientált programozás egyik alapvető fogalma. Olyan osztályt ír le, amely más osztályok egy vagy több objektumára hivatkozik példányváltozókban. Ez lehetővé teszi az objektumok közötti has-a kapcsolat modellezését.” Így írja le itt a Stackify. Gondolj rá úgy, mint egy zenekarra. Egy előadó szép, de ha az egész együttes együtt van, a zene gazdagabb és mélyebb.”
előnyök
A megfelelő kompozícióval létrehozott kód fő előnye az újrafelhasználás. Ha helyesen tervezed meg, akkor könnyen újrafelhasználhatónak kell lennie. Ha nem, akkor elég nehézkes lehet. Ezzel együtt egy intuitív és tiszta API vagy alkalmazásprogramozási felület. Tapasztalt Java programozóként számos embert hallottam már panaszkodni a Java szálkezelő API tervezése miatt. A jó tervezésnek lehetővé kell tennie, hogy valamit belsőleg megváltoztassunk, és ne változtassuk meg, hogy mások hogyan lépnek vele kapcsolatba.
Példák
Készítsünk egy példát, hogy lássuk, hogyan néz ki a kompozíció Java-ban.
Itt definiáltuk a Role osztályunkat.
A Role osztályt ebben az Employee osztályban használjuk. A kompozícióban azt mondanánk, hogy az Employee osztály “has-a” Role.
Hiding
A mi API példánkban a HotDogGrinder és HotDogGrill osztályok package-private-ek és kívülről nem érhetők el.
Itt van az API-nk nyilvános arca, a HotDogMachine. Ez az osztály hivatkozik arra a két belső osztályra, amelyet az API kialakításunkkal elrejtünk.
Kompozíció vs. öröklés
A kompozíciót és az öröklést a fejlesztők összekeverhetik. Ahogy Steven Lowe ebben a ThoughtWorks blogbejegyzésben rámutat, körültekintően kell megválasztanunk, hogy melyiket használjuk.
Megosztja a gyakran hallott ökölszabályt: “részesítsük előnyben a kompozíciót az örökléssel szemben”. Mint minden hüvelykujjszabály esetében, meg kell értenünk, hogy nem mindig érvényesek. Ezért tisztázzunk néhány dolgot, mielőtt továbbmennénk.
Meghatározzuk az öröklést, mivel a kompozícióról már hosszasan beszéltünk. Az öröklés az objektumorientált programozás egyik alapja. Például, ha van egy élelmiszer osztályunk, akkor a kenyér osztály örökölne az élelmiszer osztályból. Míg a kompozíció olyan elemekkel foglalkozik, amelyek egy nagyobb egység részét képezik.
Lowe emlékeztet minket arra, hogy amikor bármelyiket használhatnánk, két különböző kérdést kell feltennünk. Az első: “A tartományi fogalmaink reprezentációja/megvalósítása az egyik dimenzió”. Lényegében ha mindkettő ugyanabban a tartományban van, akkor valószínűleg az öröklés a legjobb választás. Másodszor: “A tartományi fogalmaid szemantikája és egymáshoz való viszonyuk a második dimenzió”. Az általad létrehozott komponensek elkezdik továbbítani a másikat ez lehet a jele annak, hogy újra kell gondolnod az öröklés használatát helyette.”
A kompozíció a szoftverfejlesztés egyik nagy alapelve, amit sokunk, szakemberek közül sokan elrontanak. Én magam is ezt tettem, mivel olyan megoldásokat hoztam létre, amelyek nem közelítették meg helyesen. Egy gyors whiteboard megbeszélés egy kollégával vagy valaminek a felvázolása egy darab papírra segíthet megérteni, mikor van “has-a” kapcsolat két objektum között. Miután ezt végigolvastad, meg kell értened az előnyeit is, és tudnod kell, hogyan használd egy példában. Próbáljon meg néhány példát építeni és használni, akkor tudni fogja, hogy jó úton jár-e, vagy talán az öröklés jobb út lenne.