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

2. Als je de principes goedtoepast...Heeft je code de volgende eigenschappen: Flexibel: De structuur laat verandering toe. Robuust: Je kunt delen wijzigen zonder dat anderedelen kapot gaan. Herbruikbaar: Delen van het programma zijn inandere programmas toe te passen. 3. Als je de principes niet goed toepast..Heeft je code de volgende eigenschappen: Inflexibel: de structuur maakt veranderingenmoeilijk. Fragiel: kleine veranderingen hebben grotegevolgen. Rigide: Alle delen zijn strek verweven.Dit zijn eigenschappen van wat Bob Martin code smellnoemt (komen we op terug). 4. Design patterns Dienen als voorbeeld voor het toepassen van designprinciples. Hoger niveau dan design principles: gaat overspecifieke programmeer taal / paradigma (maar nogsteeds niet over programma domein). Concreet: is in code uit te drukken. 5. Code Smell 6. Wanneer de design principles niet (goed) wordentoegepast, ontwikkeld de code bepaaldeeigenschappen.Smelly code wordt steeds moeilijker (duurder) om meete werken.Als code smell te erg wordt ontstaat er code rot: hetwordt t moeilijk veranderingen door te voeren.Refactoring! 7. RigiditeitMoeilijk te veranderen.Als het moeilijk is om (zelfs kleine) veranderingen in decode door te voeren. 8. FragiliteitMakkelijk kapot te maken.Wanneer een programma op meerdere, of onverwachteplekken kapot gaat bij wijzigingen op een plek. 9. ImmobiliteitHergebruik is moeilijk.Wanneer het moeilijk is om code te ontwarren totfunctionele componenten. 10. ImmobiliteitHergebruik is moeilijk.Wanneer het moeilijk is om code te ontwarren totfunctionele componenten. 11. StroperigheidWanneer het makkelijker is om het verkeerde te doen.Wanneer a te moeilijk wordt aanpassingen te doen inovereenstemming met het ontwerp. Wijzigingen wordenals hacks gemplementeerd. 12. OverdesignWanneer de complexiteit van de code groter is dande toepassing vraagt.Het ontwerp bied of anticipeert op ongevraagdefunctionaliteit, met als gevolg dat de structuur onnodigcomplex is. 13. Design principlesEen overzicht 14. Open/Close PrincipleCode moet open zijn voor uitbreiding, maar geslotenvoor verandering.Scheid code die niet moet veranderen van code die welmag veranderen (template pattern) of het gebruik vanabstracties (strategy pattern). Denk framework!Uitgangspunt: het moet niet nodig zijn bestaande codeaan te passen om nieuwe functionaliteit toe te voegen. 15. Single responsibility principle Een class moet slechts een verantwoordelijkheid (ofrol) hebben. Deze rol moet volledig worden gemplementeerd doorde 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 hebbendie dit doel duidelijk omschrijft. Functies die meerdere dingen doen moeten wordenopgesplitst. Functies met control flow moeten alleen de flowbevatten, de (optionele) acties worden aparte functies. 17. Maximum CohesieCohesie is de mate waarin de onderdelen van eenmodule bij elkaar horen. De delen van een module moeten sterk verwant zijn. De delen van een module mogen niet sterk verwantzijn met delen van een andere module 18. Principle of leastastonishment"mensen zijn deel van het systeem. Het ontwerp zou opde voorgaande ervaringen, verwachtingen en instellingvan de gebruiker moeten aansluiten."Code moet zijn functie tot uitdrukking brengen: Code moet doen wat je verwacht. Code moet goed leesbaar zijn: korte blokken, goedenaamgeving. Het ontwerp moet de functie uitdrukken. 19. Principle of Least Knowledge Minimaliseer afhankelijkheidEen object moet zo weinig mogelijk weten over destructuur of velden van andere objecten.Formeel gezien zou functie m van object o alleenmoeten praten met: Andere functies van o. ms parameters. Objecten door m genstantieerd. Direct aan o verwante objecten. 20. Principle of Least Knowledge Maak de publieke interface van een module zo kleinmogelijk, verberg de implementatie en de variabelen(state). Dependency injection: Instantieer nooit modules ineen module. Regel afhankelijkheden extern. Laat een functie van module A nooit een instantievan module B terug geven. Korte lijnen. Praat zo weinig mogelijk met andere modules. 21. Hollywood principle(Dont call us, well call you) Minimaliseer koppeling Centraliseer de controle flow binnen je programma. Laat de controller de functionaliteit in je modulesaanroepen (events). De modules roepen de controller nooit aan. Gebruikcallbacks. De call richting gaat altijd n kant op. 22. The end.