OBJEKTORIENTERING++

Objektorientert programmering (OOP) ble oppfunnet (eller oppdaget som Nygaard pleide å si) av Kristen Nygaard og Ole-Johan Dahl på Norsk Regnesentral på midten av sekstitallet i form av programmeringsspråket Simula. Siden har denne måten å utvikle programmer på gått sin seiersgang over hele verden. Alle de grunnleggende ideene i Simula har blitt kopiert (med stor kommersiell suksess) i en rekke nyere språk – inklusive Smalltalk, C++, Objective C, Delphi, Eiffel og nå til slutt Java. I forbindelse med at Norsk Regnesentral denne måneden feirer 40-års-jubileum kan det være interessant å reflektere over hva som er årsaken til at OOP har fått slikt et gjennomslag, og om hva som eventuelt ligger i framtiden.

Den «klassiske» programmodellen nedfelt i programmeringsspråk som Algol, Pascal og C, er at et program er en sekvens av instruksjoner som utføres en etter en. For å slippe å gjenta instruksjons­sekvenser som utføres ofte innførte man en mekanisme som man kalte for en subrutine. En subrutine er et program i miniatyr. Når en subrutine skal starter opp oppstår et sett med flunkende nye lokale variable som subrutinene benytter til sine interne hjelpeberegninger. Når subrutinen er ferdig med jobben og har beregnet et resultat returnerer den til hovedprogrammet for å fortsette der det slapp for å utføre subrutinen. Og vips, så forsvinner de lokale variablene som subrutinen gjorde bruk av.

I objektorienterte språk, som Simula og Java, finnes det i stedet for subrutiner en konstruksjon som kalles for «en klasse». Hva er en klasse? Kort og godt er det en subrutine med hukommelse. I stedet for at den oppstår fra det tomme intet hver gang det er bruk for den, og forsvinner sporløst etter bruk, vil den interne tilstanden til en klasse overleve så lenge en instans av klassen lever. Bruker vi hver enkelt instans av klassen bare en enkelt gang før vi kaster den, oppfører den seg nøyaktig som en subrutine. Men lar vi klassen få lov til å leve lenger er det som skjer nesten magisk! Plutselig kan programmet vårt forholde seg til flere samtidige prosesser, avbrytelser og tilstandsendringer på en langt mer direkte og naturlig måte enn i programmeringsspråk som er konstruert slik at subrutiner glemmer alt om sin tilstand i det øyeblikk de forlates.

Det bør vel for ordens skyld legges til at OOP i dag også dreier seg om andre ting – slike ting som innkapsling, arv og polymorfisme. Men for meg er det fortsatt de abstrakte datatypene – subrutiner med hukommelse – som framstår som selve genistreken i OOP. Det er disse som gjør det mulig å lage programmer som ganske direkte modellerer prosess- og substansaspektene ute i «den virkelige verden» og dermed gjør det langt lettere å lage komplekse programsystemer som samvirker med tilsvarende strukturer i sine omgivelser. Og like nyttige er abstrakte datatyper når jeg ønsker å lage interaktive programmer hvor omgivelsene (og ikke programmet) skal ha kontrollen. Slike programmer må kunne avbrytes når som helst, for eksempel av viktige data som strømmer inn via nettverket, eller rett og slett fordi brukeren gir en ny beskjed. Og fordi klasser kan leve videre selv om de forstyrres av slike avbrudd gjør OOP det enkelt og naturlig for meg å lage programmer som tillater en høy grad av brukerinteraksjon.

Det er i dag utenkelig for meg å lage programmer på en annen måte enn ved OOP. Er vi så ved OOP i mål med hensyn til metodeutvikling, eller kan ting fortsatt gjøres bedre?

Vel, blant dem som utfordrer dagens praksis er Kristen Nygaard. Nå tilbake som forsker på Norsk Regnesentral – og i gang med å ta neste logiske skritt i utvikling av metoder og verktøy for utvikling av komplekse datasystemer.

Nøkkelordet er «ensemble». Et «ensemble» er en gruppe aktører som opptrer sammen og hvor samspillet mellom aktørene skaper et hele. Et fotballag hvor hver spiller kjenner sin plass og sin oppgave er et ensemble. En veltrenet teatertrupp som oppfører et stykke sammen en annen. Ideen bak å innføre ensemblebegrepet i programmering er å skape et kraftigere og mer anvendelig abstraksjoner enn de vi kjenner fra OOP. Ensembler og aktører kan være programkomponenter, men de kan også være noe ganske annet, «fremmede» systemkomponenter, fysiske prosesser utenfor datamaskinen, til og med menneskelige aktører.

I langt sterkere grad en tradisjonell OOP tillater ensembletankegangen oss å modellere samspillet mellom alle de ulike komponentene i komplekse, sammensatte, samvirkende og distribuerte systemer. Et eksempel er den ikke uvanlige situasjonen i et systemutviklingsprosjekt hvor systemet skal inkludere allerede eksisterende applikasjoner («legacy applications») og halvfabrikata i from av moduler fra ulike underleverandører. Typiske anvendelsesområder er intranettapplikasjoner, systemer for datastøttet samarbeide, elektronisk handel, søkemotorer og nettverksportaler – kort sagt alle slags prosjekter hvor det er bent fram umulig eller uøkonomisk å selv utvikle og ha total kontroll over alle grensesnitt og komponenter som inngår i det komplette systemet.

Lykke til, Norsk Regnesentral, med 40 årsdagen! Og lykke til med utviklingen av de metoder som resten av verden skal bruke de neste 40 år på å kopiere!

---

Først publisert i: PC World Norge, nr. 12, 1998
Copyright © 1998 Gisle Hannemyr. Noen rettigheter reservert.
Dette verk gjøres tilgjengelig under en Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License.

---