Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

Realisering av Software Patterns Software Design Patterns Realisering med kode Refaktorering Gjenkjenning av mønstre.

Liknende presentasjoner


Presentasjon om: "Realisering av Software Patterns Software Design Patterns Realisering med kode Refaktorering Gjenkjenning av mønstre."— Utskrift av presentasjonen:

1 Realisering av Software Patterns Software Design Patterns Realisering med kode Refaktorering Gjenkjenning av mønstre

2 Mønstre fra ulike paradigmer •GoF beskriver 24 instanser av mønstre •GRASP beskriver 9 instanser av best practices •XP Agile beskriver 11 prinsipper for objektorientert design •Andre beskriver tusenvis av instanser for vellykket struktur

3 Eksempel fra GoF •Mønsteroversikter kan vises i UML pakkediagram •Merk at Adapter brukes både på klasse- og objektnivå •GoF beskriver derfor 23 typer, men 24 instanser, av mønstre.

4 Mønstre kan bygge på hverandre •Larman viser hvordan f. eks. GoF Adapter bruker mange av prinsippene i GRASP •Tom DeMarco viser hvordan Single Responsibility Principle kan assosieres med kohesjon •Page-Jones viser det samme med high cohesion

5 Sammenhenger •GoF Adapter realiserer mange av prinsippene i GRASP •Det samme gjelder for flere prinsipper innenfor GRASP •… og det samme kan sies om mange flere patterns i GoF •GRASP inneholder mange av de grunnleggende ideene (Larman 2005, side 439)

6 Interface og enum •Interfacet deklarerer metoder og konstanter •Interface kan ikke instansieres •Interface følger Liskovs prinsipp, og kan være argumenter •Klasser og interface kan bruke enum for å deklarere og definere metoder knyttet til sekvenser av objekter

7 Praktisk bruk av enum

8 Praktisk bruk av interface •Domeneklassene kan realisere interface •Interfacet deklarerer argumentene •Liskovs prinsipp kan også brukes for interface members

9 Klasser og abstraksjoner •Klassen beskriver objektene •Klassen eier et klasseobjekt som eksisterer allerede før instansiering •Abstrakte klasser følger Liskovs prinsipp, og kan være argumenter •Den abstrakte klassen deklarerer metoder og datafelt, definerer noen av metodene men kan ikke instansieres

10 Interface members •Feltet figureList er en member •Klassen Figure er abstrakt •Domeneklassene bindes til en abstrakt struktur med robust design

11 Interface-abstraksjon-struktur •Kombinasjonen av interface, abstrakte klasser og domeneklasser erstatter komplisert logikk •For eksempel kan LineElement enkelt utnyttes for å bygge nye grafiske begreper (former)

12 Mønstre og assosiering •Action-objekter kan starte en kommandokjede som realiserer Chain-of- Responsibility •De samme action-objektene kan være i flere instanser av Decorator på en gang •Action-objektet assosieres med dekoratøren gjennom aggregering •Grafiske brukerkontroller assosieres med sin parent gjennom komposisjon

13 Abstrakte metoder •Klasser med abstrakte metoder blir selv abstrakte •Metoden write i OutputStream må være abstrakt fordi –Write må kunne skrive til ulike medium •Tcp/ip, printer eller lokalt filsystem med tape, harddisk, floppy, CD, DVD osv … •Vi vet ikke hvilket medium som skal skrives •Likevel både vil og kan vi lage ferdig andre metoder som baserer seg på write

14 Abstraksjon og spesialisering •Klassen FileOutputStream kan spesialisere OutputStream •Ved spesialiseringen realiseres metoden write for skriving til ”fil” i det lokale filsystemet •Dermed slutter klassen å være abstrakt, og kan instansieres

15 Sub/superklassing og aggregering •Tunge klasser som svikter f. eks. SRP eller high cohesion, kan deles i partielle klasser •Abstrakte klasser subklasses i white-box design •Aggregering gir ofte enklere design og klarere ansvarsfordeling •Subklassing av framework-klasser kan forenkle designen

16 Praktisk subklassing av framework •Vector kan reduseres med tilfeldige elementer i en subklasse-design

17 Typesterk subklassing •Typedefinert Hashtable subklasses til multippel nummergenerator

18 Subklassing og klasseobjekt •Subklassing kan føre til kompliserte tilstander •Bruk av klasseobjekter forenkler syntaksen for tilstander •Klassetilstander (static variabler) kan også forenkle logikken betydelig •Men klassetilstander kan være utsatt for race conditions

19 Race conditions og tråder •Race conditions kan oppstå fordi objekter fra ulike tråder bruker felles ressurser •Metodene kan beskyttes med ordet synchronized •Tråder kan programmeres med ulike metoder som sparer CPU-tid •For eksempel kan sleep slippe monitoren for et angitt antall millisekunder

20 Eksempel på tråd •class Kakler extends Thread •Klassen må redeklarere metoden ”run” •Klassen Kakler brukes i simpletransport og simpletidy –for å overføre informasjon fra et sted til et annet –Uforstyrret og uten selv å forstyrre –Lar brukeren få tilgang til brukerkontroller før io er helt gjennomført


Laste ned ppt "Realisering av Software Patterns Software Design Patterns Realisering med kode Refaktorering Gjenkjenning av mønstre."

Liknende presentasjoner


Annonser fra Google