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.
Wat bedoelen we dan met compositie? “Compositie is een van de fundamentele concepten in object-georiënteerd programmeren. Het beschrijft een klasse die verwijst naar een of meer objecten van andere klassen in instantievariabelen. 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 van code die met de juiste compositie is gemaakt, is hergebruik. Als je het goed ontwerpt, zou het gemakkelijk te hergebruiken moeten zijn. Zo niet, dan kan het behoorlijk omslachtig zijn. Samen met dat is 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 worden verward. 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, omdat we het al uitvoerig over samenstelling hebben 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. Waar compositie te maken heeft met elementen die deel uitmaken van een grotere eenheid.
Lowe herinnert ons eraan dat wanneer je een van beide zou kunnen gebruiken we twee verschillende vragen moeten stellen. Ten eerste: “De representatie/implementatie van je domeinconcepten is één dimensie.” In wezen, als beide in hetzelfde domein zijn, is overerving waarschijnlijk je beste gok. 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 inheritance 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 het doorlezen zou je ook de voordelen moeten begrijpen en weten hoe je het in een voorbeeld kan gebruiken. Probeer een aantal voorbeelden te bouwen en te gebruiken, dan zou je moeten weten of je op de goede weg bent of dat inheritance misschien een betere weg is.
Kijk naar meer geweldige inhoud en schrijf je in op MyITCareerCoach.com
