Historik: OOP (forts)

(1)

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)

Objectorienterad programmering Sida 1

Introduktion Sven-Olof Nyström

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

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

Modularitet

(Enligt Meyer)

• Problemlösning

• Återanvändning

• Förståelse

• Underhåll

• Felsökning

(2)

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

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

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

Exempel (en klass Person):

public class Person {

private String name;

private int age;

public Person (String n, int a) { name = n;

age = a;

}

(3)

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;

} }

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)

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

• Metodanrop-skicka meddelande till ett objekt

Skapa & kommunicera med objekt, exempel

Person olle = new Person ("Olle", 7);

olle.hello();

(4)

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)

Exempel på icke-OO:

• 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

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 () { ... } }

Arv, exempel

Employee john = new Employee("John", 23, 123456);

john.hello();

john.setSalary(1234567);

(5)

Vi kan om-definiera metoden hello() i Employee.

public void hello() { super.hello();

System.out.println("Jag tjänar "+ salary);

}

john.hello();

Polymorfi:

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.

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

Värmesystem, skiss

regulator Värme−

Timer

Rum(x) närvaro

Värmepanna Rum(x)

vattenventil Rum(x) temperatur

gränssnitt Användar−

(6)

• 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

Värmepannan

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.

Hur löser man detta?

Ansats 1: klasser enligt figur.

En komplex klass (Heat-flow regulator), övriga mycket enkla.

Dålig OOP! Lösningen lägger hela ansvaret på en klass.

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

(7)

Klassen Furnace, andra ansats

två metoder:

void setRunning(boolean b);

boolean getRunning();

Uppstartsproceduren implementeras i klassen Furnace.

även regler för hur snabbt pannan kan startas om etc.

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

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

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

(8)

En lösning:

Kalla metoderna nåt annat, tex void setHeatRequired(boolean b) boolean getHeatRequired();

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

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?

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

(9)

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

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

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

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