Abstrakta Klasser 2. Kodning är bara en liten del i programvaruutvecklingen 6% 1% 6% Abstrakta Klasser - deklaration. Programutveckling sker i faser

Transkript

1 Abstrakta Klasser 1 God klassdesign placerar gemensamma attribut och metoder så högt som möjligt i hierarkin men ibland kan dessa egenskaper inte definieras fullständigt Abstrakta klasser innehåller ofta abstrakta metoder En abstrakt metod har ingen implementation, bara en signatur Klasser med abstrakta metoder blir abstrakta Abstrakta klasser är ofta för allmänna för att vara direkt användbara En abstrakt klass kan inte instantieras 83 Abstrakta Klasser 2 /* * Draw the figure on screen. */ protected abstract void draw(); // Canvas canvas = Canvas.getCanvas(); // canvas.setforegroundcolour(color); // construct an appropriate Shape object // and call `canvas.fill() with this // `Shape object // canvas.wait(10); Bara metodhuvudet /* * Erase the figure on screen. */ protected abstract void erase(); // Canvas canvas = Canvas.getCanvas(); // construct an appropriate `Shape object and // call `canvas.erase() with this `Shape object 84 Abstrakta Klasser - deklaration public abstract class Classname attribut deklareras implementerade metoder abstrakta metodhuvuden 67% Kodning är bara en liten del i programvaruutvecklingen 6% 1% 6% 5% 7% 8% Analys Planering Design Kodning Testning Integration Underhåll 85 Programmen måste göras lättförståeliga och enkla att modifiera, rätta och bygga ut 86 Problemlösning Många projekt misslyckas, eftersom utvecklarna inte till fullo förstår problemet som ska lösas Alla antaganden måste klargöras Möjliga feltolkningar måste undanröjas När problem blir större, måste lösningen delas in i hanterliga delar Denna teknik är fundamental för programvaruutveckling I objektorienterad utveckling delas lösningen in i så kallade objekt och klasser Java är ett objektorienterad språk 87 Programutveckling sker i faser Här: starkt förenklat version Passar bara mindre projekt Fem delmoment: Fastställa och analysera förutsättningarna/kraven Skapa en design Implementera koden Testning Dokumentation OBS! Testning och dokumentation ska ske parallellt med de övriga momenten. 88 1

2 OOA&D Analys Förstå problemet / uppgiften Utveckla en OO modell av problemet Design Utveckla en OO modell av lösningen Modeller underlättar kommunikation Oberoende av programspråk Abstraherar från oväsentliga detaljer Underlättar testning i tidigt skede CRC-kort UML (ett modelleringsspråk för OO utveckling) 89 Fastställa och analysera förutsättningarna/kraven Vad ska göras? Vilka begränsningar finns? Är alla oklarheter utredda? Gör modeller/utkast Undvik att tänka på implementationen 90 Skapa en design Implementation Bestäm klasser, objekt och metoder som behövs Vad finns redan? Bestäm algoritmer för problemlösningen I princip oberoende av programmeringsspråk Diagram Pseudokod Designa för återanvändning? Det är svårare att göra generella lösningar Kan löna sig i framtiden Återanvändning har varit en stor anledning till OOboomen 91 Översättning av design till källkod Implementationen fokuserar på kod-detaljer Alla viktiga beslut tas vid analys och design 92 Testning och dokumentation Tester måste konstrueras för extremer, svagheter och gränsfall Med tester ska fel finnas och inte undvikas Testa tidigt och ofta Det är inte bara kod som kan testas Dokumentera fortlöpande ANALYS SYSTEM DESIGN PROGRAM DESIGN V modellen Validera kraven Verifiera designen KODNING SYSTEMTEST ENHETS- & INTE- GRATIONSTEST DRIFT & UNDERHÅLL ACCEPTANS- TEST

3 Vad kännetecknar en god klass En odelad, väldefinierad abstraktion Uppgiften kan beskrivas kort och tydlig Namnet är en substantiv eller adjektiv som beskriver abstraktionen på ett adekvat sätt Har ett koncist och sammanhörig gränssnitt Har tillstånd och beteende Representerar en mängd möjliga run-time objekt Problemet ska delas upp i lämpliga klasser Cohesion och Coupling (sammanhörighet och koppling) Metoderna i varje klass ska ha stark sammanhörighet Cohesion Varje metod ska vara ansvarig för bara en uppgift Cohesion mäter huruvida en metod uppfyller detta krav Ju mer en metod fokuserar på en enda uppgift, desto enklare är det att finna ett bra namn enklare och förståeligare blir koden Metoder med stark sammanhörighet kan lättare ändras utan att andra metoder påverkas Det ska vara möjligt att beskriva en metod med en enkel mening med ett verb och ett objekt Klasserna ska vara löst kopplade (oberoende av varann) Exempel 1: Cohesion: Exempel 1 public void setnameandage (String name, int age); public void setname (String name); public void setage (int age); Exempel 2: /* Anropas en gång om året */ public void calculateholidays(); holidays += new Holidays(); age++; public void calculateholidays(); public void incrementage(); 97 Exempel 3: Cohesion: Exempel 2 public void setfirstname (String name) firstname = name; public void setlastname (String name) lastname = name; public void setfirstname (String name) firstname = name; public void setlastname (String name) lastname = name; 98 Kategorier av metoder Konstruktorer Skapa instanser Selektor (get-metod) Returnerar information om objektets tillstånd Mutator (set-metod) Ändra objektets tillstånd Iteratorer Gå igenom en kollektion elementvis Returnerar ett objekt och fortsätter till nästa Annat Gör någonting Coupling Klasserna ska vara så oberoende som möjligt av varandra Coupling mäter hur starkt klasserna är kopplade Ju lösare klasserna är kopplade, desto enklare är det att förstå en enstaka klass enklare och förståeligare blir systemet som helhet Klasserna med lös koppling kan lättare ändras utan att andra klasser påverkas Systemet blir lättare att ändra Mera flexibilitet PROBLEM: Arv skapar starka kopplingar En metod ska vara bara i en kategori

4 Ju starkare relation desto starkare koppling ( sämre) svag koppling Dependency Association Komposition Arv Klassrelationer igen <<beror på>> relation Grafisk notation - int height - int width - int xposition - int yposition - String color Triangle + Triangle ( ) + changecolor (String newcolor) + changesize (int newheight, int newwidth) + move ( ) + float getarea ( ) + boolean isequilateral ( ) // liksidigt?... stark koppling Sekvensdiagram (UML) OOA&D med CRC-kort Analys Förstå problemet/uppgiften Utveckla en OO modell av problemet Design Utveckla en OO modell av lösningen Modeller underlättar kommunikation Oberoende av programspråk Abstraherar från oväsentliga detaljer Underlättar testning i tidigt skede CRC-kort UML(ett modelleringsspråk för OO utveckling) Rollspelsdiagram 105 CRC-kort Class-Responsibilities-Collaborators Klass-ansvar-sammarbetspartner Ett CRC-kort motsvarar en klassbeskrivning (alt. Objekt) Informellt verktyg för att ta fram och utvärdera olika alternativ 106 4

5 CRC Metoden Grupparbete(4-6 personer) Hitta kandidatobjekt m.h.a brainstorming Filtrera kandidatobjekten Skapa CRC-kort för kvarvarande kandidatobjekt Definiera scener för testning av modellen (testfall) Spela in scener m.h.a sekvensdiagram (testa) Uppdatera CRC-korten och scenerna Efter några senarion När CRC-korten är någorlunda stabila kan de göras om till mera formella klassdiagram Design