Soliciteren in een bounded context
Bij de software development vacatures zie ik vaak dingen staan als: “Kennis van: KISS == Keep it small and simple DRY == Don’t Repeat Yourself AHA == Avoid Hasty Abstractions DIE == Duplication is Evil S.O.L.I.D. == Single Responcibility, Open Closed, Liskov Substitution, Interface Segregation, Dependency Inversion G.R.A.S.P. : 9 Fundamentele principes van OOD”
In dat rijtje is DRY en SOLID erg populair. Maar daar is wat op af te dingen. Neem het DRY princiepe. Don’t Repaet Yourself, luien developers zijn goede developers want ze willen alles maar een keer typen hoor je developers wel eens zeggen. Maar dit princiepe kan ook een antie patroon worden. Om alles maar een keer te willen schrijven loop je de kans dat je die Class die je gemaakt hebt maar blijft uitbreiden, om maar te voldoen aan alle verwachtingen en gebeurtenissen die ondersteund moeten worden. Door een Order Class maar een keer te willen schrijven, en deze te willen gebruiken in verschillende scenario’s zal de class groeien. In de order moeten bijvoorbeeld de artikelen komen, de betaal status, de order picking gegevens, de shipping gegevens enz. Het aantal regels van de Class neemt toe. En daarmee waarschijnlijk de cyclomatic complexity*. *uitleggen*
Het zelfde kan gebeuren met de SOLID princiepes hoewel in mindere mate. #Vpprbeeld