1 Voorwaarden hergebruik Modulair ontwerp Low coupling High cohesion.

Presentatie over: "1 Voorwaarden hergebruik Modulair ontwerp Low coupling High cohesion."— Transcript van de presentatie:

1 1 Voorwaarden hergebruik Modulair ontwerp Low coupling High cohesion

2 2 Modularity Modularity is the property of a system that has been decomposed into a set of cohesive and loosely coupled modules [Booch] (blz. 235)

3 3 Low coupling Koppeling is een maat voor de mate waarin een element verbonden is met kennis heeft van vertrouwd op andere elementen. (blz. 229)

4 4 High/strong coupling verandering in de interface heeft gevolgen voor vele classes moeilijk te begrijpen slecht herbruikbaar

5 5 High cohesion Cohesion is een maat voor de mate waarin de verantwoordelijkheden van een element gerelateerd zijn. (blz. 233)

6 6 Low cohesion moeilijk te begrijpen moeilijk herbruikbaar moeilijk onderhoudbaar wordt vaak gewijzigd

7 7 Voorbeeld cohesion/coupling Onderscheid functionele en relationele cohesion

8 8 Relationele cohesion Maatstaf voor een package: aantal interne relaties / aantal types(classes) (blz. 477) Interne relatie omvat attribuut en parameter relaties overerving interface implemenaties

9 9 Practicum: Cohesion/Coupling

10 10 Categorieën patterns Structural Behavioural Creational Architectuur Client/Server Design Adapter Indirection/Mediator Factory Composite Iterator Singleton Controller Observer Decorator Polymorfisme Facade Strategy MVC Proxy Idioms Singleton

11 11 Client - Server

12 12 Client - Server

13 13 Model View Control

14 14 Controller Probleem: Welke class is verantwoordelijk voor de verwerking van een system event. Oplossing:Een controller class die hoofdzakelijk delegeert. Vaak kent een systeem diverse controllers Anders is er wellicht sprake van een bloated controller.

15 15 Adapter Probleem: De classes A, B, … die onderling verschillende interfaces hebben, maar met één interface moeten communiceren met class Z. Oplossing: Gebruik een Adapter class die de interface converteert.

16 16 Decorator Probleem: Soms moet een object van extra functionaliteit kunnen worden voorzien. Oplossing: Voeg het runtime object toe aan een ander object dat deze functionaliteit bezit.

17 17 Facade: probleem

18 18 Facade: oplossing

19 19 Proxy Proxy is een plaatsvervanger gevolgmachtigde Probleem: Het creëren van een object is “duur” en wellicht overbodig. Oplossing: Gebruik een proxy die indien nodig het benodigde object creëert.

20 20 Proxy voorbeeld

21 21 Indirection/Mediator Probleem: Een groep objecten communiceert onderling veel. De classes zijn door sterke coupling moeilijk herbruikbaar. Oplossing: Gebruik een Indirection class die de onderlinge communicatie verzorgt.

22 22 Indirection nodig

23 23 Indirection toegepast

24 24 Iterator / cursor Probleem: Hoe verkrijgt men van een aggregaat de individuele objecten zonder de interne structuur te tonen. Oplossing: Gebruik een Iterator object. Java: Enumeration, Iterator, List interface; LinkList class

25 25 Observer Probleem: Verschillende objecten zijn geïnteresseerd in specifieke veranderingen van object X. Oplossing: Definieer een subscriber of listener interface. Java: implements ActionListener; Observer interface en class Observable.

26 26 Polymorfisme Probleem: Hoe om te gaan met verschillende classes met gedeeltelijke overeen- komstige functionaliteit. Oplossing: Definieer een interface met de overeenkomstige functionaliteit.

27 27 Polymorfisme voorbeeld class Hoofd { A a; // heeft interface Algemeen B b; // heeft interface Algemeen public Hoofd() { a = new A("test"); b = new B(23); }

28 28 Polymorfisme voorbeeld public static void main(String[] args) { Hoofd hoofd1 = new Hoofd(); hoofd1.demo(); } void demo() { doeIets(a); doeIets(b); } void doeIets(Algemeen x) { x.drukaf(); }