Helheten är större än summan av delarna
-Aristoteles
Detta citat tillskrivs Aristoteles. Den grundläggande poängen handlar om synergieffekter. I Stephen Coveys bästsäljande bok The 7 Habits of Highly Effective People är hans sjätte vana att skapa synergieffekter. Det som gäller för organisationer gäller även inom datavetenskapen. Ett föremåls kropp är mer värdefull än dess enskilda individ. Inom datavetenskap använder vi begreppet komposition.
Composition
Så vad menar vi med komposition? ”Komposition är ett av de grundläggande begreppen inom objektorienterad programmering. Det beskriver en klass som hänvisar till ett eller flera objekt från andra klasser i instansvariabler. Detta gör det möjligt att modellera en has-a-association mellan objekt.” Så här beskriver Stackify det här. Tänk på det som en orkester. En artist är trevlig, men när du har hela gruppen tillsammans blir musiken rikare och djupare.
Fördelar
Den största fördelen med kod som skapats med korrekt komposition är återanvändning. Om du utformar den på rätt sätt bör den vara lätt att återanvända. Om inte så kan det bli ganska besvärligt. Tillsammans med detta finns ett intuitivt och rent API eller gränssnitt för tillämpningsprogrammering. Som erfaren Javaprogrammerare har jag hört många människor beklaga sig över utformningen av Javas tråd API. En bra design bör göra det möjligt för dig att ändra något internt och inte ändra hur andra interagerar med det.
Exempel
Låt oss skapa ett exempel så att vi kan se hur sammansättning ser ut i Java.
Här har vi vår Role-klass definierad.
Role-klassen används i den här Employee-klassen. I komposition skulle du säga att Employee-klassen ”has-a” Role.
Hiding
I vårt API-exempel är klasserna HotDogGrinder och HotDogGrill paketprivata och kan inte nås utifrån.
Här är den offentliga sidan av vårt API, HotDogMachine. Den här klassen har en referens till de två interna klasserna som vi döljer med vår API-design.
Composition vs Inheritance
Composition och inheritance kan förväxlas av utvecklare. Som Steven Lowe påpekar i det här blogginlägget från ThoughtWorks måste vi välja noggrant vilken vi ska använda.
Han delar med sig av den ofta hörda tumregeln ”favorisera komposition framför arv”. Som med alla tumregler måste vi förstå att de inte alltid gäller. Så låt oss få några saker i ordning innan vi går vidare.
Låt oss definiera arv eftersom vi redan har talat länge om komposition. Arv är en av grunderna för objektorienterad programmering. Om vi till exempel har en matklass så skulle brödklassen ärva från matklassen. Medan komposition handlar om element som är en del av en större enhet.
Lowe påminner oss om att när man skulle kunna använda antingen eller måste vi ställa två olika frågor. Först: ”Representationen/implementeringen av dina domänbegrepp är en dimension”. I huvudsak om båda är inom samma domän är arv förmodligen det bästa alternativet. För det andra: ”Semantiken hos dina domänkoncept och deras förhållande till varandra är en andra dimension”. De komponenter du skapar börjar vidarebefordra till en annan detta kan vara ett tecken på att du kanske behöver ompröva att använda arv istället.
Sammansättning är en stor princip inom mjukvaruutveckling som många av oss yrkesverksamma klantar till. Jag har själv gjort det när jag skapat lösningar utan att närma mig den på rätt sätt. En snabb whiteboarddiskussion med en kollega eller att skissa något på ett papper kan hjälpa dig att förstå när det finns en ”has-a”-relation mellan två objekt. Efter att ha läst igenom detta bör du också förstå fördelarna och veta hur du ska använda det i ett exempel. Försök att bygga något exempel och använd det så bör du veta om du är på rätt spår eller om arv kanske är en bättre väg.
.