Tag single-responsibility principe

Test-driven development is een ontwerpdiscipline

Een collega benaderde me laatst met een vraag over een stuk code. Hij was bezig met het implementeren van een feature om een toets met afbeeldingen om te zetten naar een PDF-representatie ervan. Zijn vraag was: hoe kom ik aan die afbeelding? Of liever: waar kom ik aan die afbeelding? Zijn eerste ingeving was om via dependency injection de relevante repository mee te geven aan de ImagePdfGenerator. - Het is een klassiek geval van het verknopen van het ophalen van data en het manipuleren ervan. Ik bleef wel met een knagend gevoel achter: hoe makkelijk blijkt het om dankzij een DI-container de verantwoordelijkheden van classes te verwateren - en wat moeten we daarmee?

Wat is jouw mentale model?

Eerder schreef ik erover waarom het zo belangrijk is om code die data ophaalt te scheiden van code die data manipuleert. Ik kan me voorstellen dat ik lezers heb die denken: joh, dit zijn toch allemaal open deuren? Misschien hebben die lezers gelijk. Maar aan de andere kant: het aantal keren dat ik code heb kunnen verbeteren door het ophalen en manipuleren van data te scheiden, vertelt een ander verhaal. Wellicht loont het zich om daarom kort te reflecteren op een aantal redenen waarom deze goede gewoonte niet stevig verankerd is in het hoofd van elke ontwikkelaar.

Scheid data ophalen van data manipuleren

Het aantal refactoravonturen (met goede of slechte afloop) dat ik heb beleefd is, inmiddels al lang niet meer op één hand te tellen. In de loop der tijd is een terugkerend fenomeen me opgevallen: code waarin het ophalen van data niet wordt gescheiden van het manipuleren ervan. Laten we dat eens wat nader bekijken.

Wat is de O in SOLID nog waard?

Een ontwikkelaar die eens code schrijft en deze nooit meer aan denkt te hoeven passen, is een ontwikkelaar die rot in zijn applicatie verwelkomt. Een al te strikte naleving van het Open-closed principe (OCP) getuigt van een ronduit onverantwoorde houding - in elk geval binnen de context van Agile ontwikkeling. Waar komt de aantrekkingskracht van het OCP dan vandaan?

De leercurve van Angulartests beklimmen - deel 2

In een vorige blog beschreef ik de keuze van mijn team om de front end van onze Angular-applicatie te testen via end to end-tests - en waarom we daar uiteindelijk op terugkwamen. Nu we besloten hadden inderdaad te willen (nee, moeten) unit testen, doemde er een nieuwe keuze op in de beslisboom: gaan we ons in het zweet werken om Angulars steile leercurve te beklimmen, of bekijken we of er een manier is waarop we het testen voor ons kunnen vergemakkelijken?

Enums, switch statements en SOLID - deel 4

Vorige week refactorde ik een switch statement rondom een enum aan de hand van het Dependency inversion principe. Deze week zetten we onze refactorslag voort aan de hand van het de O in SOLID: het Open-closed principe. Zo voorkomen we dat we onze code hoeven te herschrijven, elke keer als we onze enum aanpassen.

Enums, switch statements en SOLID - deel 3

Vorige week refactorde ik een switch statement rondom een enum aan de hand van het Single-Responsibility principe. Deze week zetten we onze refactorslag voort aan de hand van de D in SOLID: het Dependency inversion principe. Tijd om de interfaces van stal te halen!

Enums, switch statements en SOLID - deel 2

Vorige week liet ik een stuk code zien dat op verschillende manieren de SOLID-principes schond. Deze week gaan we aan de hand van het Single-Responsibility principe een eerste stap zetten deze code te refactoren om hem wat makkelijker onderhoudbaar te maken.

Enums, switch statements en SOLID - deel 1

Onlangs stuitte ik op een stuk code dat ik de dagen erop maar niet uit mijn hoofd kreeg. (Ik ben er nog niet helemaal over uit of dat tekenend is voor mijn passie voor en/of professionaliteit als softwareontwikkelaar, of voor mijn langzame aftakeling gedurende de coronacrisis.) Het ging om een switch statement rond een enum. De komende weken zal ik deze code refactoren om aan SOLID principes te voldoen.