Abstractie

Disclaimer: ik ga het woord abstractie, en andere woorden, hier zeer ruim gebruiken. Genuanceerde uitspraken kunnen even de boom in.

Abstractie komt bij software-ontwikkeling vaak voor. Je maakt objecten die een database voorstellen waardoor met een eenvoudige method-call je object automagisch in de database wordt gestopt. Dat is het goede type abstractie.

Het slechte type abstractie is de reden waarom ik hier en daar een grijze haar ontdek. Data-access-objects (DAOs) zijn een mooi voorbeeld. Het idee: je maakt een interface met de ondersteunde functies – vind de gebruiker met id 5, sla een nieuwe gebruiker op – en schrijft daarna de implementatie voor een bepaalde database; Oracle, MySQL, etc. In de rest van de code gebruik je dan een object van het type van de interface, dat op de een of andere manier een instantie van de werkelijke implementatie verbergt.

In 99,9% van de gevallen is dit waardeloos want er wordt maar één type database ondersteund. Zorgt het gebruik van interfaces voor problemen? Nee, niet echt. Maar de configuratie hiervan wel. Ergens moet je duidelijk maken dat je voor interface X een instantie van class Y verwacht. Cue XML files.

Ik ben een Java-developer. Maar ik denk dat ik ondertussen meer XML DTD’s en Schema’s ken dan core Java API. De web.xml file. De Spring servlet files. De Hibernate XML files (granted: je kan het ook in Java, waarvoor dank). Struts config. Tiles. Validators.

Dat onnozel gedoe moet eens gaan stoppen. Ik ben langer bezig met het opzetten van een project en het aanpassen van XML files dan met het schrijven van Java-, HTML- of CSS-code. Oh ja, je kan snel dingen aanpassen in XML files zonder de hele applicatie opnieuw te moeten deployen. Yay! Tien minuten gewonnen in de pruimentijd.

Stop het. Please.

Dit artikel werd opgenomen in ontwikkeling.