Presentatie design principles

409 views
332 views

Published on

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

Published in: Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
409
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
2
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Presentatie design principles

  1. 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. 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 programmas toe te passen.
  3. 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 smellnoemt (komen we op terug).
  4. 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. 5. Code Smell
  6. 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. 7. RigiditeitMoeilijk te veranderen.Als het moeilijk is om (zelfs kleine) veranderingen in decode door te voeren.
  8. 8. FragiliteitMakkelijk kapot te maken.Wanneer een programma op meerdere, of onverwachteplekken kapot gaat bij wijzigingen op een plek.
  9. 9. ImmobiliteitHergebruik is moeilijk.Wanneer het moeilijk is om code te ontwarren totfunctionele componenten.
  10. 10. ImmobiliteitHergebruik is moeilijk.Wanneer het moeilijk is om code te ontwarren totfunctionele componenten.
  11. 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 geïmplementeerd.
  12. 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. 13. Design principles Een overzicht
  14. 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. 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. 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. 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 verwant zijn met delen van een andere module
  18. 18. Principle of least astonishment"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, goede naamgeving.● Het ontwerp moet de functie uitdrukken.
  19. 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 geïnstantieerd.● Direct aan o verwante objecten.
  20. 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. 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 modules aanroepen (events).● De modules roepen de controller nooit aan. Gebruik callbacks.● De call richting gaat altijd één kant op.
  22. 22. The end.

×