Objektorienterad programmering Emil Ahlqvist (c10eat@cs.umu.se) Didrik Püschel (dv11dpl@cs.umu.se) Johan Hammarström (c08jhm@cs.umu.se) Hannes Frimmel Moström (c10hml@cs.umu.se) 1
1. Introduktion 1.1 Objektorienterad Programmering 1.2 Historia 2. Abstrakta datatyper 2.1 Abstraktion 3. Information hiding 3.1 Om Information Hiding 4. Message passing 4.1 Definition 4.2 Anvädning 4.3 Funktion 4.4.1 Exempel: Java 4.4.2 Exempel: Smalltalk 4.5 Framtiden 5. Arv 5.1 Programkodsåteranvändning 5.2 Definition av arv 5.3 Överskuggade metoder 5.4 Enkelt respektive multipelt arv 2
1. Introduktion 1.1 Objektorienterad Programmering Objektorienterad programmering är en programmerings paradigm där program kan betraktas som en uppbyggnad och interaktioner av objekt. Definition Objekt Klass En samling av substantiv som representerar data(attribut) och verb(metoder) som representerar funktioner En konstruktion som kan skapa instanser av sig själv. En klass representerar oftast ett substantiv, en instans av en klass kallas objekt. 1.2 Historia Det första framträdande av objektorienterad som det används i modern mening var i sent 50 tal och tidigt 60 tal i MIT då i sammanhang av forskning av artificiell intelligens. Objekt som ett formelt koncept introducerades under 60 talet av Simula 67, ett språk designat för händelsestyrd simulering. Simula introducerade klasser och instanser av klasser som en del av en programmerings paradigm. Programmeringsspråket Smalltalk utvecklat under 70 talet introducerade termen objektorienterad programmering för användning av objekt och messaging (see 4.) som basen för beräkningar. Smalltalk och OOP blev introducerade till en bredare publik 1981 via en artikel i Byte Magazine. Objektorienterad programmering blev dominant i början till mitten av 90 talet då programmeringsspråk med stöd för OOP blev allmänt tillgängliga. En bidragande orsak för OOP dominans var populariteten av GUI som bygger OOP tekniker. Exempel C++. På senare tid har språk utvecklats som är huvudsaklingen objektorienterade men har stöd för imperativ programmering därför att det är effektivare vid beräknigar av primitivare datatyper. Exempel Java. 3
2. Abstrakta datatyper 2.1 Abstraktion (Tomt) 4
3. Information hiding 3.1 Om Information Hiding Information Hiding är Abstraktion, med den grundläggande iden att avändaren inte ska kunna komma åt data, snarare än som det varit tidigare, då programeraren helt enkelt var tvungen att hoppas att användaren inte ändrar eller rör data utan givna funktioner. Detta har nu ändrats till det att i många språk är det helt enkelt inte möjligt att röra vid data direkt utan att programmeraren har gjort detta möjligt, då detta inte är default. Information Hiding är faktiskt äldre än OO, olikt arv och message passing. Detta då problemet med användare som petar runt i data de inte borde vara i har varit ett problem nästintil sedan saker och ting började. För att kämpa mot detta har man gjort många olika trick för att försöka komma runt detta, till exempel förkompilerade sub program och header files för att kunna använda dem. Detta lade grunden till OO, och då arv och message passing arbetades in så var OO ett faktum. 5
4. Message passing 4.1 Definition Message Passing har två olika betydelser, beroende på situationen och vem det är som talar. Den första betydelsen är en mer idealistisk syn på OO programmering, där Objekt frågar varandra saker och de svarar. I denna version är alla objekt oberoenda av varandra. Detta är dock endast en idealistisk syn, då detta skulle kräva en tråd per objekt, och detta är inte praktiskt möjligt än. Den andra betydelsen är den mer praktiska som inte är baserad på utopia utan vad some praktiskt sker i verkligheten. I denna version är Message Passing inte mer än ett dynamiskt sätt att anropa funktioner. I detta dokument kommer vi endast att referrera till denna mer praktiska betydelse, då den idealistiska kan bli mycket viktig i framtiden men för tillfället inte har mycket faktisk användning. Mer om detta senare. 4.2 Anvädning Message Passing används mer eller mindre endast i relation till Arv, då arv är omöjligt utan Message Passing, medans det i sig själv har begränsad användning och helt enkelt inte är praktiskt att implementera utan arv. På grund av detta så används inte Message Passing till mer än detta, och kan ses som en del av Arv. 4.3 Funktion Hur fungerar då Message Passing? Detta beror naturligtvis på språket och direct implementation, och vi kommer här att visa två översiktliga exempel. Det bör noteras att vi inte kommer att gå i exakt detalj på implementation, då detta är mindre viktigt, och alla exempel som ges kommer att vara oerhörda förenkligar med ett pedagogiskt syfte, och bör inte tas som sanningar för hur saker och ting fungerar rent praktiskt. Vad är då Message Passing? Förenklat kan man säga att varje objekt har en lista med sina funktioner. När en funktion ska anropas går man igenom denna lista fram till dess att man hittar funktionen, alternativt kan säga att funktionen inte existerar i objektet. Om den inte finns så går sökandet vidare i föräldra klasser, fram till dess att man med säkerhet kan säga att funktionen inte finns i det arv trädet. Om en funktion inte finns måste detta hanteras exempel på detta finns längre ner i kapitlet. På grund av detta är Message Passing mycket långsammare än imperativ programering, det spelar ingen roll hur mycket språket är optimerat, det är helt enkelt så mycket mer som behöver göras för varje program anrop. I sin renaste form är också Message Passing ett fulständigt runtime baserat, där funktioner kan 6
skapas och tas bort medans programmer kör, och 4.4.1 Exempel: Java Ett exempel på ett språk med Message Passing är Java. Medans Java har möjligheten att avända Message Passing fullt ut är detta inte default, utan måste göras med hjälp av Reflection ett specifikt bibliotek för att göra just detta. Det normala sättet för java är en halv version av normal message passing, då mycket av det som normalt görs vid runtime är gjort vid compile. Detta är mestadels type checking och liknande, samt att java garanterar att alla funktioner finns ett program kan inte kompileras om inte alla funktioner finns implementerade. På grund av detta finns det inget fall då en funktion saknas, och sådant behöver man då inte oroa sig för. Man kan också notera att vissa primitiva datatyper, såsom boolean och int inte är object baserade och har inte Message Passing. Detta är på grund av att Message Passing inte är snabbt, och man har gjort avvägningen att i dessa fall är hastigheten viktigare än att ha allt OO. 4.4.2 Exempel: Smalltalk Ett av de språk som är känt för dess strikta användning av OO och Message Passing är Smalltalk. Detta språk implementerar ett fullständigt Message Passing, från ett Runtime type check för alla funktioner till det att allting är Objekt, till och med en int eller boolean. Detta gör att Smalltalk är oerhört enkelt att ändra i, och språket är gjort för att man ska kunna ändra i klasser i runtime utan att behöva kompilera om. En av de mer kända och använda IDEs använder detta och, då IDEn är skriven i Smalltalk, kan ändras under körning utan problem. Dock så kommer detta med en del problem, även om man ignorar den långsammare hastigheten. Detta är att det inte finns någon garanti för att en funktion finns, och man kan således få problem med detta. Smalltalk har en speciel funktion för detta, som kan överskuggas för att kunna göra saker och ting om en funktion saknas, såsom att försöka hitta den i ett annat objekt. 4.5 Framtiden Det är mycket svårt att säga vad framtiden kommer att hålla för Message Passing, dock så är det inte helt osannolikt att den utopiska versionen kommer att bli starkare då flerkärniga datorer är mer och mer populärt, vilket gör trådar inte bara mer praktiska, utan rent av ett måste. 7
5. Arv 5.1 Programkodsåteranvändning Under mitten till slutet på 1980 talet blev det uppenbart för många programmerare att en av de bästa möjligheterna för ökad produktivitet inom deras yrke var software reuse (programkodsåteranvändning). Abstrakta datatyper med deras inkapsling och accesskontroll fungerar väldigt bra för denna återanvändning. Problemet dock med återanvändningen av abstrakta datatyper är att i nästan samtliga fall så är de funktioner och egenskaper hos den existerande klassen inte helt rätt för de nya. Den gamla klassen kräver åtminstone någon eller några små ändringar. Sådana ändringar kan vara väldigt svåra att utföra, eftersom personen som ska göra dessa ändringar i många fall inte är programmets ursprungliga skapare och därför måste sätta sig in i större delen av, om inte all, kod. Förutom detta krävs även att dessa modifikationer måste utföras på flera ställen i koden.. Arv erbjuder en lösning på detta problem. Om en ny abstrakt datatyp kan ärva data och funktionalitet av någon befintlig typ, och också är tillåten att ändra på några av dessa enheter och lägga till nya enheter, underlättas återanvändningen avsevärt. Programmerare kan då med hjälp av arv använda en existerande abstrakt datatyp och forma den för att passa kraven för ett nytt problem. 5.2 Definition av arv Arv inom objektorienterad programming är, enkelt förklarat, när en klass kan härledas från en annan existerande klass. En klass som defineras genom arv från en annan klass kallas för barnklass eller subklass. Klassen som den nya klassen härleds från kallas för föräldraklass eller superklass. Inom objektorienterad programmering kan man använda sig av olika former av accesskontroll för t.ex. attribut och metoder i en klass. Förutom private och public finns även en tredje kategori, ofta kallad för protected. Protected används för att ge tillgång till attribut och metoder enbart till de härledda klasserna inom en arvshierarki, medan de undanhålls från andra klasser. 8
5.3 Överskuggade metoder En överskuggad metod hos en subklass har ofta samma namn och samma protokoll som föräldraklassens metod. Den nya metoden åsidosätter då metoden i föräldraklassen. Det vanligaste syftet med en överskuggande metod (engelska: overriding method) är att tillhandahålla en operation som är specifik för objektet av den härledda klassen, som inte är lämplig för objekt av föräldraklassen. Tänk er att vi har följande klasshierarki. En klass som kallas Vehicle, vilken har attribut för tillverkningsår och färg, samt en metod draw för att illustrera fordonet. Tänk er sedan att vi har en subklass Car till Vehicle som då ärver attributen och metoden draw från fordonsklassen, men där vi lägger till attribut för att beskriva motorkapacitet och antal hjul, samt överskuggar metoden draw från föräldraklassen för att kunna rita ut bilens särskilda utseende. Figur 1: Illustration över hur klassen Car ärver egenskaper från Vehicle, samt lägger till egna attribut specifika för en bil. 5.4 Enkelt respektive multipelt arv Om en klass är en subklass till en ensam föräldraklass kallas denna härledningsprocess för enkelt arv. När en klass däremot har mer än en föräldraklass kallas processen för multipelt arv. C++ och Eiffel är språk som stöder multipelt arv. Java och C# däremot använder sig av så kallade interfaces, som kan ses som en annan typ av multipelt arv. Ett interface kan formellt ses som en klass, men får inte innehålla egen kod. All sådan kod måste istället ligga i klasser som implementerar interfacet. Även fast multipelt arv kan vara väldigt användbart stöds det inte av alla objektorienterade programmeringsspråk. Anledningen till detta beror på att användandet av multipelt arv lätt kan leda till komplexa program. Många som försöker använda sig av multipelt arv har upptäckt att designen av de klasser som skall användas som multipla föräldrar ofta är svåra att implementera. En annan nackdel som uppstår är att det blir svårt för kompilatorn att lägga ut effektiv kod för detta. 9
Ett klassiskt exempel som illustrerar varför multipelt arv inte används i de flesta objektorienterade språk kan visas med hjälp av varselsen Kentaur från den grekiska mytologin, som är hälften häst och hälften människa. För att uppnå den önskade effekten är det lägligt att använda sig av multipelt arv och låta klassen Centaur dra nytta av egenskaperna från både en klass som beskriver en häst och en klass som beskriver en människa samtidigt. Den praktiska användningen av multipelt arv visar på svårigheterna, främst för programmeraren att överblicka effekterna av koden. Om vi fortfarande tänker oss Kentaurexemplet: om både klassen Horse och klassen Human ärver från en klass Mammal. Då kommer Centaur att innehålla två instanser av Mammal, modifierade på lite olika sätt av Horse respektive Human. Alltså kan vissa operationer bli oklart definierade, eller framförallt svåra att överblicka. Detta scenario kallas för ett diamantproblem. Figur 2: Illustration av kentaur exemplet. Vilket nämndes ovan stöder C++ multipelt arv genom att tillåta mer än en klass att vara förälder till en ny klass. Kodexemplet nedan visar hur arvshierarkin för Centaur kan implementeras. class Mammal { }; class Human : public Mammal { }; class Horse : public Mammal { }; class Centaur : public Human, public Horse { }; Klassen Centaur ärver i exemplet ovan alla egenskaper från Human och Horse, samt de redan ärvda egenskaperna från superklassen Mammal. Om både Human och Horse råkar inkludera egenskaper med samma namn, kan de otvetydigt refereras i objekt av klassen Centaur genom att använda scope resolution operatorn som finns i C++. 10