Objektorienterad programmering

Transkript

1 Objektorienterad programmering Föreläsare: Assistenter: Ruslan Fomkin,??? Obligatoriska uppgifter En uppgift om grunderna i Java och OOP (deadline 7 nov) En huvuduppgift: Design 14 nov Deluppgift a 28 nov Deluppgift b 12 dec Objectorienterad programmering Sida 1 Objectorienterad programmering Sida 3 Kursens upplägg Kurssida: Kursens innehåll 14 Föreläsningar (plus en repetition) 2 Obligatoriska uppgifter 3 Laborationstillfällen (arbete med inlämningsuppgifterna) Java & dess standardbibliotek Programmeringsmetodik, analys och design: allmänna principer för OOP, UML, Design patterns, refactoring lite om andra OOP språk Tentamen 22/12 Objectorienterad programmering Sida 2 Objectorienterad programmering Sida 4

2 Litteratur Xiaoping Jia: Object-Oriented Software Development using Java Dessutom: OH-blad från föreläsningar, material från webben. Historik: OOP (forts) C++, Bjarne Stroustrup, Bell Labs Bygger på C med idéer från Simula och Algol-68 Saknar GC Eiffel, Objective C, Object Pascal, Self Java Objectorienterad programmering Sida 5 Objectorienterad programmering Sida 7 Simula-67 Norge, 1967 Historik: OOP Byggde på Algol-60, avsett för simulering Garbage collection, arv, klasser (inte olikt Java) Smalltalk, Alan Kay, Xerox, 70-tal Introducerade begreppet objekt-orienterad programmering Första GUIna skrevs i Smalltalk (och i Lisp) Andra begrepp Idéer som fanns före OOP men som blivit en del av OOP: Abstraktion Modularitet Inkapsling Software engineering Metoder för analys, design Objectorienterad programmering Sida 6 Objectorienterad programmering Sida 8

3 (Enligt Meyer) Problemlösning Återanvändning Förståelse Underhåll Felsökning Modularitet Principer för OOP (Alan Kay) Allt är ett objekt (dvs alla datastrukturer representeras som objekt). Ett program är en samling objekt Objekten skickar meddelanden till varandra Varje meddelande är en begäran om en handling (aktion) som ska utföras Varje objekt har sitt eget minne Ett objekt kan bestå av andra objekt Objectorienterad programmering Sida 9 Objectorienterad programmering Sida 11 Software engineering Begreppet myntades i en NATO-konferens Problem: Software crisis Önskemål: Samma pålitlighet och produktivitet som i de traditionella ingenjörskonsterna (tex brobyggen, mekaniska konstruktioner,...) Lösning: Formalisera de olika stegen i programutvecklingen: Kravanalys, Design, Implementation, Testning, Underhåll Principer för OOP (forts) Varje objekt tillhör en klass En klass representerar ett visst beteende alla objekt som är instanser av samma klass kan utföra samma aktioner. Klasser organiseras i en trädliknande arvshierarki. En klass ärver beteende och datastrukturer från tidigare klasser Objectorienterad programmering Sida 10 Objectorienterad programmering Sida 12

4 Historik: Java Hette från början OAK (James Gosling, 1991). Utvecklades vid SUN Microsystems. Från början avsett för inbyggda system (tex tvättmaskiner, mobiltelefoner, TV/video, spel, mm). (Storlek och pålitlighet var viktiga) Med WWW fick projektet en annan inriktning Java blev ett programspråk för web-applikationer Kompilering av Java Traditionella kompilatorer översätter programtexten till maskinkod. De flesta Java-kompilatorer översätter till en slags maskinkod; Javabytekod (JVM). Det finns inga maskiner som kör Javabytekod (nja, nästan inga). Därför måste JVM-koden vid körning antingen översättas till maskinkod, eller interpreteras. Objectorienterad programmering Sida 13 Objectorienterad programmering Sida 15 (Man brukar säga att) Java är... enkelt baserat på C/C++ objekt-orienterat från början dynamiskt utbyggbart robust, säkert oberoende av hårdvaruarkitektur (portabelt) web-anpassat: applets, div bibliotek Utvecklingsverktyg för Java Senaste versioner är J2SE samt J2SE 5.0 J2SE 5.0 (även känt som Java 1.5) innehåller viktiga utökningar, inte helt bakåtkompatibelt. Vi fokuserar på Java 5. Objectorienterad programmering Sida 14 Objectorienterad programmering Sida 16

5 On-line dokumentation När man arbetar med Java behöver man dokumentation av alla standardklasser. Suns tutorial Person (forts): public void hello() { System.out.println("Jag heter"+ namn +" och är "+ age +"år gammal."); public void setname (String n) { name = n; public String getname () { return name; Objectorienterad programmering Sida 17 Objectorienterad programmering Sida 19 Exempel (en klass Person): public class Person { private String name; private int age; public Person (String n, int a) { name = n; age = a; Viktiga koncept: En klassdefinition med instansvariabler och metoder instansvariablerna inre tillstånd metoderna sätt att interagera med objekt (ungefär som funktioner i C) Objectorienterad programmering Sida 18 Objectorienterad programmering Sida 20

6 Koncept (forts) Varje objekt tillhör en klass Varje objekt har instansvariabler/fält enligt def Varje objekt tillåter interaktion via publika metoder private endast tillgängligt inom klassdefinition public tillgänglig överallt konstruktor Vad är OOP? Ett OO program är en värld befolkad av kommunicerande objekt objekt kommunicerar genom att skicka meddelanden objekt vet inget om varandras inre tillstånd (annat än vad som kan härledas indirekt) Metodanrop-skicka meddelande till ett objekt Objectorienterad programmering Sida 21 Objectorienterad programmering Sida 23 Exempel på icke-oo: Skapa & kommunicera med objekt, exempel Person olle = new Person ("Olle", 7); olle.hello(); stoppa in all information i ett objekt använd objekt ungefär som struktar i C objekt med otydligt ansvar vagt definierade gränssnitt Objectorienterad programmering Sida 22 Objectorienterad programmering Sida 24

7 Ytterligare begrepp: Arv public class Employee inherits Person { private int salary; public Employee (String n, int a, int s) { super(n, a); salary = s; public void setsalary (int s) {... public int getsalary () {... Vi kan om-definiera metoden hello() i Employee. public void hello() { super.hello(); System.out.println("Jag tjänar "+ salary); john.hello(); Objectorienterad programmering Sida 25 Objectorienterad programmering Sida 27 Polymorfi: Arv, exempel Employee john = new Employee("John", 23, ); john.hello(); john.setsalary( ); Anta att vi har fler klasser (Student, Teacher,...) samt en array av personer: Person[] alla = new Person[10]; alla[0] = olle; alla[1] = john;... for(int i = 0; i++; i<10){ alla[i].hello(); Regel: objektet "vet" vilken klass det tillhör. Objectorienterad programmering Sida 26 Objectorienterad programmering Sida 28

8 Exempel: Kontrollsystem för uppvärmningssystem (Booch) kommer inte att ge en detaljerad lösning viktiga är inte den färdiga lösningen utan processen dit nej, så här fungerar det inte (åtminstone inte i Sverige) brist med detta exempel: statisk objektstruktur vi skapar aldrig nya objekt Användargränssnitt: temperaturgivare för varje rum värmeledningsventil för varje rum Timer sensor, infraröd eller rörelse- lagra information för att förutse användning värmepanna Objectorienterad programmering Sida 29 Objectorienterad programmering Sida 31 Värmesystem, skiss Användar gränssnitt Värmepannan Rum(x) temperatur Rum(x) vattenventil Värme regulator Timer Rum(x) närvaro Kontrollen av pannan är komplex (fläkt, oljepump, tändning) Om pannan stoppats måste det ta minst 5 minuter innan den startas om. Pannan startas om minst ett rum behöver värme. Värmepanna Objectorienterad programmering Sida 30 Objectorienterad programmering Sida 32

9 Hur löser man detta? Enkel lösning: klasser enligt figur. En komplex klass (Heat-flow regulator), övriga mycket enkla. två metoder: Klassen Furnace, andra ansats void setrunning(boolean b); boolean getrunning(); Uppstartsproceduren implementeras i klassen Furnace. Dålig OOP! Lösningen lägger hela ansvaret på en klass. även regler för hur snabbt pannan kan startas om etc. Objectorienterad programmering Sida 33 Objectorienterad programmering Sida 35 Hur hitta lämpliga klasser? Skissa bottom-up. Leta efter naturliga klasser Vi måste förenkla problemet klasstrukturen bör ge ledning i hur man bryter ner i naturliga delproblem Enkelt gränssnitt Alternativ 2, fördelar flyttar komplexitet från Heat-flow regulator gör det lättare att använda kontrollsystemet med andra typer av pannor ev kan koden som kontrollerar pannan användas i andra sammanhang Objectorienterad programmering Sida 34 Objectorienterad programmering Sida 36

10 Furnace, en komplikation Om pannan just stängts av och setrunning(true) anropas, vad ska Furnace göra? gör som du blir tillsagd och sk-t i konsekvenserna (dvs 5-minutersregeln implementeras nån annanstans) låtsas som inget, vänta 5 minuter och sen starta Värmesystem, forts Idé: inför en klass Rum. Varje rum håller reda på önskad temp nuvarande temp närvaro ventil talar om ifall det behöver värme Vilket ansvar återstår för värmeflödesregulatorn? Objectorienterad programmering Sida 37 Objectorienterad programmering Sida 39 Furnace, mer krångel Ska getrunning returnera true eller false när du väntar? true, det är mera konsistent med hur get&set förväntas fungera false, annars ljuger vi En lösning: Kalla metoderna nåt annat, tex void setheatrequired(boolean b) boolean getheatrequired(); Närvaro Ett rum ska betraktas som i bruk om antingen någon använder det, eller det förväntas snart användas, enligt heuristik ovan Vill antagligen införa en abstraktion närvaro som tacker båda ovan Objectorienterad programmering Sida 38 Objectorienterad programmering Sida 40

11 Var placera kod som hanterar närvaro? Notera: Den heuristik som beskrivits kanske inte är den bästa. Vad göra om en person går fram och åter mellan rum? En komplex algoritm som ev måste ändras Värmesystem, klasser Panna: enkelt gränssnitt, allt som rör pannan Rum: försök hålla temp enligt önskad temp, ta hänsyn till "närvaro" Närvaro: Nuvarande och förväntad närvaro Värmeflödesregulatorn: Underrätta pannan om något rum behöver värme Objectorienterad programmering Sida 41 Objectorienterad programmering Sida 43 Värmesystem, Kommentar Lösningalternativ varje rum hanterar närvaro ett objekt närvaro, gemensamt för alla rum varje rum har sin egen närvarohanterare lösningen är lättare att förstå om varje klass inte är alltför komplicerad introducera abstraktioner val av namn på klasser och metoder kan vara viktigt hantering av närvaro är överspecificerad inte så lyckat att binda sig för en typ av panna specen borde ha skrivits annorlunda Objectorienterad programmering Sida 42 Objectorienterad programmering Sida 44