Historik: OOP Simula-67 Norge, 1967 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) Objektorientering Objektorienterade programspråk Objektorienterad programmering Objektorienterad programutveckling Objectorienterad programmering Sida 1 Objectorienterad programmering Sida 3 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 En Dum Fråga Vad vill vi åstadkomma med programspråk och utvecklingsmodeller? Java Objectorienterad programmering Sida 2 Objectorienterad programmering Sida 4
Några begrepp Idéer som fanns före OOP men blivit en del av OOP: Abstraktion Modularitet Inkapsling Software engineering Metoder för analys, design Software engineering Begreppet myntades i en NATO-konferens 1968. 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 Objectorienterad programmering Sida 5 Objectorienterad programmering Sida 7 (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 6 Objectorienterad programmering Sida 8
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 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 9 Objectorienterad programmering Sida 11 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 10 Objectorienterad programmering Sida 12
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 13 Objectorienterad programmering Sida 15 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 objekt med vagt definierade gränssnitt Objectorienterad programmering Sida 14 Objectorienterad programmering Sida 16
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 17 Objectorienterad programmering Sida 19 Polymorfi: Arv, exempel Employee john = new Employee("John", 23, 123456); john.hello(); john.setsalary(1234567); 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 18 Objectorienterad programmering Sida 20
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 21 Objectorienterad programmering Sida 23 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 22 Objectorienterad programmering Sida 24
Hur löser man detta? Ansats 1: 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 25 Objectorienterad programmering Sida 27 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 Ansats 2, fördelar Klassen Furnace får ett enklare gränssnitt 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 26 Objectorienterad programmering Sida 28
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) En lösning: Kalla metoderna nåt annat, tex void setheatrequired(boolean b) boolean getheatrequired(); låtsas som inget, vänta 5 minuter och sen starta Objectorienterad programmering Sida 29 Objectorienterad programmering Sida 31 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 Insikter... Val av namn till klasser och metoder är viktigt Viktig fråga: Var lägger man ansvaret? Sträva efter konsekvent ochförutsägbart beteende Objectorienterad programmering Sida 30 Objectorienterad programmering Sida 32
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? 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 Objectorienterad programmering Sida 33 Objectorienterad programmering Sida 35 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 täcker båda ovan Närvaro, lösningsalternativ Varje rum hanterar närvaro, ett objekt närvaro, gemensamt för alla rum, eller varje rum har sin egen närvarohanterare Objectorienterad programmering Sida 34 Objectorienterad programmering Sida 36
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 37 Värmesystem, Kommentar 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 38