Den samlede helhed er større end summen af dens dele
-Aristoteles
Dette citat tilskrives Aristoteles. Den grundlæggende pointe handler om synergi. I Stephen Coveys bedst sælgende bog 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.
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 giver mulighed for 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 fin, men når du har hele gruppen samlet, er musikken rigere og dybere.”
Fordele
Den største fordel ved kode, der er skabt med korrekt komposition, er genbrug. Hvis du designer den korrekt, bør den være nem 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 sammensætning ville man 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ænebegreber 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.
Sammensætning er et stort princip i softwareudvikling, som mange af os professionelle sjusker med. 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 en skitse 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 nogle eksempler og brug det, så bør du vide, om du er på rette vej, eller om arv måske er en bedre vej.
Kig på mere godt indhold og tilmeld dig på MyITCareerCoach.com
