Als we wat we gemaakt hebben nu in een UML vorm gieten dan ontstaat een interessant plaatje :

Er is nu scheiding ontstaan tussen applicatie specifieke klassen (de onderste helft), de framework klassen (Factory en Registry) en de Initialisatie (Main). Enkel de Main klasse heeft alle kennis in zich van de applicatie. De overige klassen zijn of onwetend of netjes gescheiden via interfaces. State of the art technology .. of niet?

Er is altijd een prijs te betalen voor het gebruik van frameworks die werken via reflectie. Ze zijn langzamer ten opzichte van echte implementaties. Daarnaast zijn ze ook een stuk ondoorzichtiger. Dat betekent als je aan het debuggen gaat en er wordt ergens een nieuw object gemaakt dat je eerst door een zooi reflectie code heen moet - dat is niet prettig.

Conclusie :

Als we flexibele software willen schrijven dan is het verstandig om de onderdelen te scheiden door middel van interfaces. Echter we hebben gezien dat het gebruik van interfaces niet automatisch leidt tot flexibele software. Het feit dat je concreet een type moet kennen om er een object van te kunnen maken gooit roet in het eten.

Er zijn drie strategieën die gebruikt kunnen worden afhankelijkheden te ontkoppelen :

• Weten - waarin via overerving in de afhankelijkheid word voldaan. Het FactoryMethod pattern doet dit bijvoorbeeld. Uiteraard blijven de subklassen wel sterk verbonden met de originele ontkoppelde klasse, wat een nadeel kan zijn.
• Opzoeken - waarin het object zelf opzoek gaat naar zijn afhankelijkheden. Met behulp van een Service Locator is dit mogelijk. Met deze methode houdt je altijd een enkel centraal (maar wel neutraal!) type over waarin de interfaces en implementaties samen komen.
• Vertellen - het object wordt verteld wat zijn afhankelijkheden zijn door middel van zijn constructor en/of een setter methods. Door middel van Dependency Injectie kan dit nagenoeg transparant zonder eindeloos parameters te hoeven doorgeven van de ene naar de andere constructor. Een alternatief vormt de AbstractFactory waarbij het aanmaken van het object wordt geabstraheerd achter een interface (waar je natuurlijk weer een implementatie van moet zien te krijgen)

De prijs die voor het ontkoppelen betaalt moet worden is afhankelijk van de gekozen technologie. Bij het gebruik van het AbstractFactory pattern zegt de (vele) code duidelijk wat het doet. Bij Dependency Injection gebeurt een hoop onderwater via reflectie - ondoorzichtig - echter het is wel een manier waarbij je veel code kunt vervangen door initialisatie en configuratie.

Handige Links :

• Het Singleton pattern in de wiki van c2.com.
• PICO Container - een super lichtgewicht IoC container
• Spring Framework - een compleet en veelzijdig IoC gebaseerd framework
• De Java-Doc van de java.lang.reflect package.
• Een artikel van Martin Fowler over dependency injection

Over de Auteur

Erik Hooijmeijer is senior developer bij 42 bv - het antwoord op de vraag van Java, Software en Rest. Naast het zo af en toe schrijven van een artikel ontwerpt en bouwt hij bedrijfskritische Java applicaties. Daarnaast is Erik nooit te beroerd om het leuke nieuwe dingen in elkaar te programmeren zoals te zien is op zijn persoonlijke website .