Introductie design principles: - wat zijn design principles? - hoe verhouden ze zich tot design patterns? - wat is code smell?

1. Wat zijn design principles
● Beschrijven hoe de onderlinge delen van een
programma zich tot elkaar moeten verhouden.
● Gaan over het structureren van de code zelf, en
niet het domein van het programma.
● Abstract: zijn niet in code uit te drukken.

2. Als je de principes goed
toepast...
Heeft je code de volgende eigenschappen:
● Flexibel: De structuur laat verandering toe.
● Robuust: Je kunt delen wijzigen zonder dat andere
delen kapot gaan.
● Herbruikbaar: Delen van het programma zijn in
andere programma's toe te passen.

3. Als je de principes niet
goed toepast..
Heeft je code de volgende eigenschappen:
● Inflexibel: de structuur maakt veranderingen
moeilijk.
● Fragiel: kleine veranderingen hebben grote
gevolgen.
● Rigide: Alle delen zijn strek verweven.
Dit zijn eigenschappen van wat Bob Martin 'code smell'
noemt (komen we op terug).

4. Design patterns
● Dienen als voorbeeld voor het toepassen van design
principles.
● Hoger niveau dan design principles: gaat over
specifieke programmeer taal / paradigma (maar nog
steeds niet over programma domein).
● Concreet: is in code uit te drukken.

5. Code Smell

6. Wanneer de design principles niet (goed) worden
toegepast, ontwikkeld de code bepaalde
eigenschappen.
'Smelly' code wordt steeds moeilijker (duurder) om mee
te werken.
Als code smell 'te erg' wordt ontstaat er 'code rot': het
wordt té moeilijk veranderingen door te voeren.
Refactoring!

7. Rigiditeit
Moeilijk te veranderen.
Als het moeilijk is om (zelfs kleine) veranderingen in de
code door te voeren.

8. Fragiliteit
Makkelijk kapot te maken.
Wanneer een programma op meerdere, of onverwachte
plekken kapot gaat bij wijzigingen op een plek.

9. Immobiliteit
Hergebruik is moeilijk.
Wanneer het moeilijk is om code te ontwarren tot
functionele componenten.

10. Immobiliteit
Hergebruik is moeilijk.
Wanneer het moeilijk is om code te ontwarren tot
functionele componenten.

11. Stroperigheid
Wanneer het makkelijker is om het verkeerde te doen.
Wanneer a te moeilijk wordt aanpassingen te doen in
overeenstemming met het ontwerp. Wijzigingen worden
als 'hacks' geïmplementeerd.

12. Overdesign
Wanneer de complexiteit van de code groter is dan
de toepassing vraagt.
Het ontwerp bied of anticipeert op ongevraagde
functionaliteit, met als gevolg dat de structuur onnodig
complex is.

13. Design principles
Een overzicht

14. Open/Close Principle
Code moet open zijn voor uitbreiding, maar gesloten
voor verandering.
Scheid code die niet moet veranderen van code die wel
mag veranderen (template pattern) of het gebruik van
abstracties (strategy pattern). Denk framework!
Uitgangspunt: het moet niet nodig zijn bestaande code
aan te passen om nieuwe functionaliteit toe te voegen.

15. Single responsibility
principle
● Een class moet slechts een verantwoordelijkheid (of
rol) hebben.
● Deze rol moet volledig worden geïmplementeerd door
de class.
● Als je een class aanpast die meerdere rollen heeft,
splits die dan op.

16. Single responsibility
principle
● Functies moeten een ding doen. En een naam hebben
die dit doel duidelijk omschrijft.
● Functies die meerdere dingen doen moeten worden
opgesplitst.
● Functies met control flow moeten alleen de flow
bevatten, de (optionele) acties worden aparte functies.

17. Maximum Cohesie
Cohesie is de mate waarin de onderdelen van een
module bij elkaar horen.
● De delen van een module moeten sterk verwant zijn.
● De delen van een module mogen niet sterk verwant
zijn met delen van een andere module

18. Principle of least
astonishment
"mensen zijn deel van het systeem. Het ontwerp zou op
de voorgaande ervaringen, verwachtingen en instelling
van de gebruiker moeten aansluiten."
Code moet zijn functie tot uitdrukking brengen:
● Code moet doen wat je verwacht.
● Code moet goed leesbaar zijn: korte blokken, goede
naamgeving.
● Het ontwerp moet de functie uitdrukken.

19. Principle of Least
Knowledge
Minimaliseer afhankelijkheid
Een object moet zo weinig mogelijk weten over de
structuur of velden van andere objecten.
Formeel gezien zou functie m van object o alleen
moeten praten met:
● Andere functies van o.
● m's parameters.
● Objecten door m geïnstantieerd.
● Direct aan o verwante objecten.

20. Principle of Least
Knowledge
● Maak de publieke interface van een module zo klein
mogelijk, verberg de implementatie en de variabelen
(state).
● Dependency injection: Instantieer nooit modules in
een module. Regel afhankelijkheden extern.
● Laat een functie van module A nooit een instantie
van module B terug geven. Korte lijnen.
● Praat zo weinig mogelijk met andere modules.

21. Hollywood principle
(“Don't call us, we'll call you”)
Minimaliseer koppeling
● Centraliseer de controle 'flow' binnen je programma.
● Laat de controller de functionaliteit in je modules
aanroepen (events).
● De modules roepen de controller nooit aan. Gebruik
callbacks.
● De call richting gaat altijd één kant op.

22. The end.