Het geheel is groter dan de som der delen
-Aristoteles
Dit citaat wordt toegeschreven aan Aristoteles. Het fundamentele punt is er een van synergie. In Stephen Covey’s bestseller The 7 Habits of Highly Effective People, is zijn zesde gewoonte: Synergize. Wat geldt voor organisaties, geldt ook in de informatica. Het lichaam van een object is waardevoller dan zijn individu. In de informatica gebruiken we de term compositie.
Compositie
Wat bedoelen we dan met compositie? “Compositie is een van de fundamentele concepten in object-georiënteerd programmeren. Het beschrijft een klasse die in instantievariabelen verwijst naar een of meer objecten van andere klassen. Hiermee kun je een has-a associatie tussen objecten modelleren.” Dit is hoe Stackify het hier beschrijft. Zie het als een orkest. Eén uitvoerder is leuk, maar als je de hele groep bij elkaar hebt, is de muziek rijker en dieper.
Voordelen
Het belangrijkste voordeel voor code die met de juiste compositie is gemaakt, is hergebruik. Als je het goed ontwerpt, moet het gemakkelijk te hergebruiken zijn. Zo niet, dan kan het behoorlijk omslachtig zijn. Daarbij komt een intuïtieve en schone API of Application Programming Interface. Als ervaren Java-programmeur heb ik veel mensen horen klagen over het ontwerp van Java’s threading API. Een goed ontwerp zou je in staat moeten stellen om iets intern te veranderen en niet om te veranderen hoe anderen ermee omgaan.
Voorbeelden
Laten we een voorbeeld maken zodat we kunnen zien hoe samenstelling eruit ziet in Java.
Hier hebben we onze Rolklasse gedefinieerd.
De Rolklasse wordt gebruikt in deze Werknemersklasse. In samenstelling zou je zeggen dat de klasse Werknemer “een” rol heeft.
Hiding
In ons API-voorbeeld zijn de klassen HotDogGrinder en HotDogGrill package-private en kunnen ze niet van buitenaf worden benaderd.
Hier is het publieke gezicht van onze API, HotDogMachine. Deze klasse heeft een verwijzing naar de twee interne klassen die we verbergen met ons API-ontwerp.
Compositie vs. overerving
Compositie en overerving kunnen door ontwikkelaars door elkaar worden gehaald. Zoals Steven Lowe in deze blogpost van ThoughtWorks aangeeft, moeten we zorgvuldig kiezen welke we gebruiken.
Hij geeft de vaak gehoorde vuistregel “geef de voorkeur aan compositie boven inheritance”. Zoals met elke vuistregel moeten we begrijpen dat ze niet altijd van toepassing zijn. Dus laten we eerst een paar dingen op een rijtje zetten voordat we verder gaan.
Laten we overerving eens definiëren, want we hebben het al uitvoerig over samenstelling gehad. Inheritance is een van de fundamenten van object-georiënteerd programmeren. Bijvoorbeeld, als we een voedsel klasse hebben dan zou brood klasse erven van de voedsel klasse. Compositie heeft te maken met elementen die deel uitmaken van een grotere eenheid.
Lowe herinnert ons eraan dat wanneer je een van beide zou kunnen gebruiken, we ons twee verschillende vragen moeten stellen. Ten eerste: “De representatie/implementatie van je domeinconcepten is één dimensie.” In wezen als beide in hetzelfde domein inheritance is waarschijnlijk uw beste weddenschap. Ten tweede, “De semantiek van je domein concepten en hun relatie tot elkaar is een tweede dimensie.” De componenten die je creëert beginnen door te sturen naar een ander, dit kan een teken zijn dat je misschien moet heroverwegen om in plaats daarvan overerving te gebruiken.
Compositie is een groot principe in software ontwikkeling dat velen van ons professionals verknoeien. Ik heb dit zelf gedaan toen ik oplossingen creëerde die het niet correct benaderden. Een snelle whiteboard discussie met een collega of het schetsen van iets op een stuk papier kan je helpen begrijpen wanneer er een “has-a” relatie is tussen twee objecten. Na dit doorgelezen te hebben zou je ook de voordelen moeten begrijpen en weten hoe het te gebruiken in een voorbeeld. Probeer een voorbeeld te bouwen en te gebruiken, dan zou je moeten weten of je op de goede weg bent of dat overerving misschien een betere weg is.