Kategori: systemutveckling

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 in­sätt­ningar, 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 meddelanden som objektet kan ta emot, utföra och svara på;
• – Objekten är också ordnade i klasser: en bank kan ha miljoner bank­konton, 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 egen­skaper. 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 stod i en databas, räntesatsen stod i en annan databas och så fanns det ett program som hämtar siffror från databaserna och beräknade 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 en högre klass ärvs auto­mat­iskt av alla underordnade klasser (om den inte blockeras);
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 ett 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. De ursprungliga princip­er­na för objektorienterade system utvecklades för slutna datorsystem där man i princip kunde överblicka allt. När det blev vanligt med distribuerade system där ett program i en dator skulle kunna utbyta information med ett program i en annan dator i ett helt annat system måste man utgå från att allt inte är ordnat på samma sätt.

– 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å lik­nande tankar. – Läs också om branschorganisationen OMG och Corba.

[systemutveckling] [ändrad 5 juni 2017]