Thursday Feb 03, 2022

Software Design Principes DRY en KISS

In dit artikel ga ik software design principes en hun voordelen verkennen, waarom design principes nuttig voor ons zijn, en hoe we ze kunnen implementeren in ons dagelijks programmeren. We zullen de DRY- en KISS-softwareontwerpprincipes verkennen.

Het DRY-principe: Don’t Repeat Yourself

DRY staat voor “Don’t Repeat Yourself,” een basisprincipe van software-ontwikkeling gericht op het verminderen van herhaling van informatie. Het DRY-principe wordt gesteld als: “Elk stukje kennis of logica moet een enkele, ondubbelzinnige representatie hebben binnen een systeem.”

Overtredingen van DRY

“We vinden het leuk om te typen” (of, “Iedereen zijn tijd verspillen.”): “We genieten van typen,” betekent het schrijven van dezelfde code of logica opnieuw en opnieuw. Het zal moeilijk zijn om de code te beheren en als de logica verandert, dan moeten we wijzigingen aanbrengen op alle plaatsen waar we de code hebben geschreven, waardoor we ieders tijd verspillen.

Hoe DRY te bereiken

Om te voorkomen dat u het DRY-principe schendt, verdeelt u uw systeem in stukken. Verdeel uw code en logica in kleinere herbruikbare eenheden en gebruik die code door deze aan te roepen waar u dat wilt. Schrijf geen ellenlange methoden, maar verdeel de logica en probeer het bestaande stuk in uw methode te gebruiken.

DRY Voordelen

Minder code is goed: het bespaart tijd en moeite, is gemakkelijk te onderhouden, en vermindert ook de kans op bugs.

Een goed voorbeeld van het DRY-principe is de helperclass in enterprise libraries, waarin elk stukje code uniek is in de libraries en helperclasses.

KISS: Keep It Simple, Stupid

Het KISS-principe is beschrijvend om de code eenvoudig en duidelijk te houden, waardoor het gemakkelijk te begrijpen is. Programmeertalen zijn immers voor mensen om te begrijpen – computers kunnen alleen 0 en 1 begrijpen – dus houd de codering eenvoudig en ongecompliceerd. Hou je methodes klein. Elke methode zou nooit meer dan 40-50 regels moeten zijn.

Elke methode zou slechts één klein probleem moeten oplossen, niet vele use-cases. Als je veel voorwaarden in de methode hebt, breek deze dan op in kleinere methoden. Het zal niet alleen gemakkelijker te lezen en te onderhouden zijn, maar het kan helpen om bugs veel sneller te vinden.

Overtredingen van KISS

We hebben waarschijnlijk allemaal wel eens de situatie meegemaakt dat we werk te doen krijgen in een project en wat rommelige code geschreven aantreffen. Dat leidt ertoe dat we ons afvragen waarom ze deze onnodige regels hebben geschreven. Kijk maar eens naar de twee onderstaande stukjes code. Beide methodes doen hetzelfde. Nu moet u beslissen welke u gaat gebruiken:

public String weekday1(int day) { switch (day) { case 1: return "Monday"; case 2: return "Tuesday"; case 3: return "Wednesday"; case 4: return "Thursday"; case 5: return "Friday"; case 6: return "Saturday"; case 7: return "Sunday"; default: throw new InvalidOperationException("day must be in range 1 to 7"); }}public String weekday2(int day) { if ((day < 1) || (day > 7)) throw new InvalidOperationException("day must be in range 1 to 7"); string days = { "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday" }; return days;}

Hoe bereikt u KISS

Om te voorkomen dat u het KISS-principe schendt, moet u proberen eenvoudige code te schrijven. Bedenk veel oplossingen voor uw probleem, kies dan de beste, eenvoudigste en zet die om in uw code. Als je lange code tegenkomt, verdeel die dan in meerdere methoden – klik met de rechtermuisknop en refactor in de editor. Probeer kleine blokken code te schrijven die een enkele taak doen.

Voordeel van KISS

Als we een bepaalde functionaliteit hebben geschreven door één ontwikkelaar en die is geschreven met rommelige code, en als we een andere ontwikkelaar vragen om wijzigingen aan te brengen in die code, dan moeten ze eerst de code begrijpen. Uiteraard, als de code eenvoudig is geschreven, dan zal er geen moeite zijn om die code te begrijpen, en zal ook gemakkelijk te wijzigen zijn.

Samenvatting

Tijdens het schrijven van een code of module, houd software design principes in gedachten en gebruik ze verstandig, maak er een gewoonte van, zodat je ze niet elke keer hoeft te onthouden. Het zal ontwikkelingstijd besparen en uw software module robuust maken, die gemakkelijk kan worden onderhouden en uitgebreid.

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.

Back to Top