objektorientering

programmering som realiseras som objekt i stället för procedurer. Numera det dominerande mönstret för hur man utvecklar större program. Man ordnar datamängderna i objekt som består både av data som hör ihop på något sätt (till exempel bankkonton) och de instruktioner som används för att bearbeta just dessa data (till exempel beräkna räntan, göra insättningar, göra uttag).
Dessa kombinationer av data och instruktioner knyts ihop i säckar som kallas för objekt.
Liknelsen med säcken syftar på så kallad inkapsling: när programmeraren väl har skapat ett objekt ska man inte komma åt data och instruktioner i koden direkt, utan bara genom ett antal definierade instruktioner som objektet kan ta emot, utföra och svara på.
Objekten är också ordnade i klasser: en bank kan ha miljoner bankkonton, men man vill inte upprepa samma kod för varje nytt konto. I stället skapas objekt för nya konton som instanser av klassen ”bankkonto”.
Klasserna ordnas i en hierarki: överst finns en klass med de egenskaper som alla bankkonton har, sedan finns det underordnade klasser som ärver den överordnade klassens egenskaper, men dessutom har särskilda egenskaper. Detta kan ske i flera led.
Det äldre mönstret för programutveckling kallas ibland för procedurorienterat, och innebar att man skilde mellan data och procedurer. Kundens behållning på bankkontot står i en databas, räntesatsen står i en annan databas och så finns det ett program som hämtar siffror från databaserna och beräknar räntan.
Objektorienterade program i renodlad form kännetecknas av:
(1) – användning av objekt, till exempel ”Nils Nilssons bankkonto”, som innehåller både data om kontot och operationer (metoder) som kan utföras med objektets data;
(2) – användning av meddelanden (metodanrop) – frågor och svar – mellan objekt vid körning av program. Ett objekt är utformat för att ta emot och verkställa endast vissa typer av meddelanden, alla andra meddelanden ignoreras;
(3) – sammanförande av liknande objekt i klasser (”Nils Nilssons bankkonto” hör till klassen ”bankkonton”) som kan ta emot och svara på samma slags meddelanden (till exempel ”beräkna räntan och skicka svaret”);
(4) – ordnande av klasser i hierarkier med arv – klassen ”bankkonton” kan ha subklasser som ”sparkonto” och ”kapitalkonto” som ”ärver” från klassen ”bankkonto” de egenskaper som alla bankkonton har gemensamt, samtidigt som de har en del speciella egenskaper. En ändring i den högsta klassen ärvs automatiskt av alla underordnade klasser;
(5) – inkapsling som innebär att ett objekt inte kan ”se” in i ett annat objekt. Vill du veta kontoställningen på ”Nils Nilssons bankkonto” måste du skicka ett meddelande till objektet, fråga och begära svar. Se metod och attribut.
Mycket av detta verkar onödigt komplicerat om man tänker sig enklare program, men i stora komplexa system är fördelarna uppenbara. Strikt tillämpning av samtliga principer för objektorientering är inte så vanligt: framför allt är det principen om att olika delar av ett system ska kommunicera genom meddelanden som tillämpas allmänt. – Objektorienteringens principer formulerades på 1960-talet av norrmännen Ole-johan Dahl och Kristen Nygaard och synsättet populariserades av Alan Kay. Hans Smalltalk är det programspråk som mest konsekvent tillämpar objektorientering. (Mer spritt är C++.) Vid samma tid var Ivar Jacobson inne på liknande tankebanor. – Läs också om branschorganisationen OMG och Corba.