SOLID Principles¶
Als Software Engineer kun je niet om de SOLID heen. Het zijn een vijftal principes die ervoor zorgen dat de broncode van een applicatie onderhoudbaar blijft. De principes zijn opgesteld door Robert C. Martin, een hele bekende naam onder de Software Engineers op de wereld. Dusdanig bekend dat hij zelfs liefkozend “Uncle Bob” wordt genoemd.
Tijdens dit project legen we heel veel aandacht op één principe, stiekem zul je dan ook al met een tweede principe en zelfs een derde in aanraking komen. Dit kenmerkt de principes ook wel: de één kan niet zonder de ander!
S: Single-reponsibility principe¶
Dit principe stelt dat alle geschreven code, op functie-niveau, al dan niet bestand/class-niveau, slechts één verantwoordelijkheid heeft.
Klinkt bekend? Dat kan! Je bent er namelijk het vorige semester al mee bezig geweest door de toepassing van MVC! Elke laag in je applicatie had immers een eigen verantwoordelijk.
Dit principe gaan we tijdens dit project nog verder doortrekken, door ook services te introduceren.
O: Open/Closed principle¶
Dit principe stelt dat geschreven code “open” moet zijn voor uitbreiding, maar “gesloten” voor aanpassing.
Klinkt cryptisch, maar het komt erop neer dat als je bijvoorbeeld een CouponService maakt om een Couponcode te controleren, dat je hier een interface (lees: niet UI-interfaces uit haalt met bijvoorbeeld een checkCouponCode(couponCode: string): boolean functie erin.
Je kunt dan meerdere implementaties van de ICouponService-interface maken, bijvoorbeeld één die tegen een Third Party API praat of direct tegen je eigen database, zonder dat bestaande code daar iets vanaf hoe te weten. De code roept immers checkCouponCode en verwacht een boolean terug, of dit nou uit een API of Database komt maakt de code niet uit! “Open” voor uitbreiding (meerdere varianten van de CouponService), “gesloten” voor aanpassing (originele code hoeft geen aanpassingen te maken als je een andere variant gebruikt).
I: Interface segregation principle¶
Dit is één van de principes waar je onbewust mee bezig gaat zijn dit project. Dit principe stelt dat kleinere interfaces (lees: niet UI-interfaces) de voorkeur genieten boven grotere interfaces.
D: Dependency inversion principle¶
Dit is ook één van de principes waar je onbewust mee bezig gaat zijn dit project. De uitleg van dit principe is echter in die context lastiger uit te leggen, maar het heeft te maken met het feit dat je met services gaat werken.
Andere principes¶
Naast SOLID heb je ook nog rekening houden met een aantal andere belangrijke principes:
- YAGNI, oftewel: You Ain’t Gonna Need It. Dit principe stelt dat je alleen code moet maken voor de zaken waarvan je zeker weet dat je het nodig gaat hebben.
- DRY, oftewel: Don’t Repeat Yourself. Dit principe stelt dat je niet onnodig code moet herhalen. Schrijf je twee keer dezelfde, dan is het waarschijnlijk beter dat herbruikbaar te maken.
- KISS, ofewel, Keep It Super Simple (of andere varianten). Dit principe stelt dat kiezen voor de simpelste oplossing vaak de beste is, tenzij je een goede rede hebt dat niet te doen. Werkt goed samen met YAGNI.
Als laatste heb je ook nog Design Patterns die je kunnen helpen met de structuur van je code.