Misbruik DRY niet

Er zijn van die principes die er bij menig ontwikkelaar al vroeg in zijn carrière ingestampt worden. “Don’t repeat yourself” is misschien wel een van de bekendste. De meeste ontwikkelaars krijgen dan om hun oren dat ze code niet mogen herhalen en dat is het dan: “Gij zult uzelf niet herhalen en als er ergens code fragmenten hetzelfde zijn, moet je refactoren.” Klinkt goed, maar in de praktijk wordt het helaas vaak contraproductief uitgelegd.

Laat me dit toelichten door het DRY-principe erbij te halen:

Er zit in de principes van DRY een addertje onder het gras: DRY gaat niet over code maar over knowledge en daarmee over gedrag. Stel dat bijvoorbeeld binnen het systeem op verschillende plaatsen een agenda-afspraak gemaakt kan worden, dan is het essentieel al deze implementaties terugvallen op één enkele waarheid. Doe je dit niet, dan zal een systeem snel onduidelijke business rules hebben met instabiliteit voor de toepassing en onduidelijkheid voor de ontwikkelaars als gevolg.

Waarom is het nu zo’n probleem wanneer dit principe ongecompliceerd wordt toegepast op code? Omdat dit kan betekenen dat twee niet gerelateerde stukken code ineens een gezamenlijke codebase delen. Stel bijvoorbeeld dat een programma zowel ordermanagement als inventorymanagement bevat:

Op basis van de bovenstaande code zou je tot de conclusie kunnen komen dat er twee identieke classes product in de toepassing zitten, en zou je deze tot één class kunnen terugbrengen. De classes representeren echter heel ander gedrag, met andere business transacties en rules. De kans dat de classes zich in de toekomst anders ontwikkelen is heel groot. Wanneer je dus deze beide classes tot één class maakt vanuit het DRY-principe creëer je een tight coupling tussen twee niet gerelateerde domeinen in de software en overtreedt je code het logische model van je applicatie.
In dit voorbeeld is het misschien voor de hand liggend dat je niet kiest voor één class, maar in de praktijk zijn er legio subtielere voorbeelden te bedenken waarbij ontwikkelaars code fragmenten hebben ondergebracht in utility bibliotheken om vervolgens met allerlei kunstgrepen de code op één plek te houden. Wanneer je binnen je code een switch nodig hebt om op basis van een type ander gedrag te selecteren, dan had deze code waarschijnlijk nooit op één plek mogen zitten.

Wat richtlijnen voor de praktijk:

Bepaal code replicatie op basis van gedrag en domein en niet op basis van de code
In geval van twijfel is het vaak beter om dubbele code het voordeel van de twijfel te gunnen en nog niet samen te trekken.