Design principes.

Transcriptie

1 Design principes

2 Doelstelling Code die werkt doet wat klant wil betrouwbaar is gemakkelijk te veranderen is En dit ook blijft doen

3 Software rot Rottende software geeft geurtjes af

4 Problemen Rigiditeit Fragiliteit Immobiliteit Plakkerigheid Overbodige complexiteit Overbodige herhaling Ondoorzichtigheid

5 Rigiditeit Systeem is moeilijk te veranderen Waterval effect Moeilijk om tijd/moeite in te schatten Fragiliteit Verandering aan systeem introduceert bugs Ook op plaatsen die je niet verwacht Waterval effect

6 Immobiliteit Systeem bevat componenten die ergens anders ook nuttig zouden zijn Maar het is te moeilijk om ze eruit te halen Plakkerigheid Het is gemakkelijk om het verkeerde te doen, maar moeilijk om het juiste te doen Moedigt hacks aan

7 Nodeloze complexiteit Systeem bevat veel hooks voor mogelijke uitbreidingen Die het begrijpen en onderhouden van het systeem moeilijker maken, terwijl de uitbreidingen er niet komen Nodeloze herhaling Copy n paste programmeren Moeilijk te onderhouden -> op verschillende plaatsen bijna dezelfde wijziging

8 Ondoorzichtigheid Huidige programmeur begrijpt code altijd beter dan latere lezer (ook als dat hijzelf is) Er is een inspanning nodig om code begrijpelijk te schrijven

9 Hoe vermijden? Kwaliteit van code constant in oog houden Proberen design geurtjes te detecteren En dan meteen oplossen

10 Expliciete beloftes Grote brok code is moeilijk te begrijpen Verschillende eigenschappen isoleren Invarianten: rekeningstand > limiet Precondities: stand - bedrag > limiet Postcondities: new.stand = stand - bedrag Vb: Bankrekening.java

11 Principes Richtlijnen om geurtjes te vermijden Principe van enkele verantwoordelijkheid Open-gesloten principe Vervangingsprincipe van Liskov Principe van de omgekeerde afhankelijkheid Principe van interface scheiding

12 Principe van enkele verantwoordelijkheid Elke klasse is maar verantwoordelijk voor een ding Elke verantwoordelijkheid is een reden om te veranderen Klasse heeft maar een reden om te veranderen Waterval effect vermijden Rigiditeit en fragiliteit vermijden

13 Bijvoorbeeld Rechthoek heeft twee verantwoordelijkheden Geometrisch concept van een rechthoek Tekenen van rechthoek

14

15 Open-gesloten principe Een klasse moet open zijn voor uitbreidingen Maar gesloten voor wijzigingen Tegenvoorbeeld: vormen.c

16 Problemen Rigiditeit: bij toevoegen van nieuwe vorm verschillende functies uit verschillende bestanden wijzigen Fragiliteit: vergissing is gauw gemaakt bij wijzigen van bestaande methode Immobiliteit: rechthoek en cirkel kunnen niet afzonderlijk gebruikt worden

17 Oplossing Beschermt tegen toevoegen/ verwijderen van vormen Tenzij...

18 Vervangingsprincipe van Liskov Object van subklasse moet object van basisklasse overal kunnen vervangen Bijvoorbeeld:

19 ook /** Een eigenschap **/ public class Ouder { een een belofte **/ public Resultaat methode(type1 arg1,..., TypeN argn) {... strenger public class Kind extends Ouder { losser een een belofte **/ subklasse public Resultaat methode(type1 arg1,..., TypeN argn) {... superklasse

20 ook /** Een eigenschap **/ public class Bankrekening { this.stand > new.stand = this.stand - n **/ public void haalaf(int n) {... strenger public class SpaarRekening extends Bankrekening { losser this.stand + this.limiet> new.stand = this.stand - n && new.rente =... **/ subklasse public void haalaf(double n) {... superklasse

21 Bijvoorbeeld

22 Principe van de omgekeerde afhankelijkheid Component x is afhankelijk van component y Als een wijziging in y ervoor zorgt dat er iets met x moet gebeuren Verandering Hercompilatie

23 Principe Het is beter dat componenten die vaak veranderen afhangen van componenten die weinig veranderen, dan omgekeerd Wat verandert er weinig? Hoog niveau Wat verander er veel? Details Het is beter dat details afhangen van hoog niveau werking, dan omgekeerd

24 Bijvoorbeeld Maak een klasse die een lijst van werknemers sorteert van jong naar oud: Zolang de lijst niet gesorteerd is, doorlopen we de lijst en wisselen elk opeenvolgend paar van werknemers dat in de vekeerde volgorde staat om

25 import java.util.*; public class PersoneelSorteerder { public List<Werknemer> lijst; public PersoneelSorteerder(List<Werknemer> l) { lijst = l; public void sorteer() { boolean gesorteerd = false; while (!gesorteerd) { gesorteerd = true; for (int i = 0; i < lijst.size() - 1; i ++) { if (lijst.get(i).getleeftijd() > lijst.get(i+1).getleeftijd()) { verwissel(i,i+1); gesorteerd = false; private void verwissel(int i, int j) { Werknemer tmp = lijst.get(i); lijst.set(i, lijst.get(j)); lijst.set(j, tmp);

26 Beter Sorteerder hangt niet meer af van Werknemer Sorteerder kan herbruikt worden voor eender welke sorteertaak

27 Ander vb

28 Principe van interface scheiding De interface van een object (dwz. hoe het zichtbaar is voor de buitenwereld) moet samenhangend zijn Clienten van klasse moeten enkel maar afhangen van die methodes die ze nodig hebben