Helheden er større end summen af dens dele
-Aristoteles
Dette citat er tilskrevet Aristoteles. Den grundlæggende pointe handler om synergi. I Stephen Coveys bestseller “The 7 Habits of Highly Effective People” er hans sjette vane at synergisere. Det, der gælder for organisationer, gælder også inden for datalogi. Kroppen af et objekt er mere værdifuld end den enkelte genstand. I datalogi bruger vi udtrykket sammensætning.
Sammensætning
Så hvad mener vi med sammensætning? “Komposition er et af de grundlæggende begreber inden for objektorienteret programmering. Det beskriver en klasse, der refererer til et eller flere objekter fra andre klasser i instansvariabler. Dette gør det muligt at modellere en has-a-forbindelse mellem objekter.” Sådan beskriver Stackify det her. Tænk på det som et orkester. Én udøver er dejlig, men når du har hele gruppen samlet, er musikken rigere og dybere.
Fordele
Den største fordel for kode skabt med korrekt komposition er genbrug. Hvis du designer det korrekt, bør det være let at genbruge. Hvis ikke, så kan det være ret besværligt. Sammen med det er en intuitiv og ren API eller Application Programming Interface. Som erfaren Java-programmør har jeg hørt mange mennesker beklage designet af Javas threading API. Et godt design bør give dig mulighed for at ændre noget internt og ikke ændre, hvordan andre interagerer med det.
Eksempler
Lad os oprette et eksempel, så vi kan se, hvordan sammensætning ser ud i Java.
Her har vi vores Role-klasse defineret.
Role-klassen bruges i denne Employee-klasse. I komposition ville du sige, at Employee-klassen “har en” Role.
Hiding
I vores API-eksempel er HotDogGrinder- og HotDogGrill-klasserne pakke-private og kan ikke tilgås udefra.
Her er det offentlige ansigt af vores API, HotDogMachine. Denne klasse har en reference til de to interne klasser, som vi skjuler med vores API-design.
Komposition vs. arvelighed
Komposition og arvelighed kan forveksles af udviklere. Som Steven Lowe påpeger i dette blogindlæg fra ThoughtWorks, skal vi vælge omhyggeligt, hvilken af dem vi skal bruge.
Han deler den ofte hørte tommelfingerregel: “Favoriser komposition frem for arv”. Som med enhver tommelfingerregel er vi nødt til at forstå, at de ikke altid gælder. Så lad os få styr på et par ting, før vi går videre.
Lad os definere arv, da vi allerede har talt længe om komposition. Arvelighed er et af fundamenterne i objektorienteret programmering. Hvis vi f.eks. har en fødevareklasse, så vil brødklassen arve fra fødevareklassen. Hvor komposition omhandler elementer, der er en del af en større enhed.
Lowe minder os om, at når man kunne bruge enten eller, skal vi stille to forskellige spørgsmål. For det første: “Repræsentationen/implementeringen af dine domænekoncepter er én dimension”. I det væsentlige, hvis begge er i det samme domæne, er arv sandsynligvis dit bedste bud. For det andet: “Semantikken af dine domænekoncepter og deres indbyrdes forhold er en anden dimension.” De komponenter, du opretter, begynder at videresende til en anden dette kan være et tegn på, at du måske skal genoverveje at bruge arv i stedet.
Komposition er et stort princip i softwareudvikling, som mange af os professionelle roder rundt i. Jeg har selv gjort det, da jeg skabte løsninger, der ikke nærmede sig det korrekt. En hurtig whiteboard-diskussion med en kollega eller at skitsere noget på et stykke papir kan hjælpe dig med at forstå, hvornår der er et “has-a”-forhold mellem to objekter. Når du har læst dette igennem, bør du også forstå fordelene og vide, hvordan du kan bruge det i et eksempel. Prøv at bygge noget eksempel og brug det, så skal du vide, om du er på rette vej, eller om arv måske er en bedre vej.