1 PROSA-Bladet nr. 4 1993 Objektorientering = Programkvalitet? Af Finn Nordbjerg, adjunkt ved Datamatikeruddannelsen, Aalborg Handelskole 1. Indledning Objektorientering er blevet et edb-fagets mest udbredte modeord. Stort set alle metoder, værktøjer og produkter reklamerer med at være "OO- dit eller dat". Pudsigt nok er dette sket i de sidste par år. Objektorientering er nemlig ikke nogen nyhed, men idéer, som er over 25 år gamle. Historien starter i Norge, hvor der udvikles et programmeringssprog, Simula, i første omgang til løsning af komplekse simuleringsopgaver, men man indser hurtigt, at de begreber og sproglige konstruktioner, der er udviklet, er velegnede til løsning af et langt større spektrum af problemer. Sproget videreudvikles, og i 1967 udbydes programmeringssproget Simula67 på markedet som et generelt programmeringssprog. Simula67 er et komplet objektorienteret programmeringssprog med understøttelse af klasser, nedarvning, polymorfi mv. Af forskellige grunde fik Simula aldrig nogen større udbredelse, men levede stille og roligt i universitetskredse rundt om i Verden - bla. i Århus og Aalborg. Simula er således meget klart forbillede for bla. C++, som i dag er et af de mest udbredte objektorienterede programmeringssprog. Det er ikke nogen tilfældighed, at C++'s "far", Bjarne Stroustrup, er datalog fra Århus Universitet. Der er altså ikke tale om en revolutionerende ny teknik, men om gode gamle idéer som har levet og udviklet sig indtil tiden var moden - og det er den øjensynligt nu. Denne artikel foregiver ikke at give et endeligt svar på overskriftens spørgsmål, men vil forsøge at give et indtryk af, hvad objektorientering er og specielt, hvordan objektorientering kan forbedre programkvaliteten.
2 2. Programkvalitet Interessen for at indføre objektorientering skyldes naturligvis, at de anvendte metoder og teknikker ikke er tilfredsstillende. Der tales ofte om, at vi har en software-krise. Symptomer herpå er bla.: systemer er ofte forsinkede, er meget dyrere end forventet, lever ikke op til brugernes forventninger og er vanskelige at ændre/tilpase. Samtidig skifter kravene til systemerne hurtigere og hurtigere, og organisationer bliver mere og mere afhængige af informationssystemer. En vej ud af software-krisen er derfor systemer, som først og fremmest er modificérbare. Modificérbarhed opnås, hvis - systemet er gennemskueligt - systemarkitekturen er stabil, dvs. at mindre ændringer i kravene til systemets funktionalitet også kun kræver mindre ændringer i enkelte af systemets moduler - ikke i systemets grundlæggende arkitektur - systemet er opbygget af moduler, som kan anvendes uden kendskab til deres interne struktur (er lukkede), men samtidig skal modulerne være åbne for ændringer/udvidelser 3. Objektorientering Objektorientering søger at opnå dette gennem, at programmer opbygges som objekter, der modellérer den virkelighed, som programmet beskriver, gennem dataabstraktion og gennem nedarvning og polymorfi (se nedenfor). Modelaspekt Et program skal være opbygget af komponenter, som svarer til begreber i programmets problemområde. Når vi tænker på de begreber, som indgår i et system, så tænker vi ikke på data og funktioner som adskilte dele, men på helheder (objekter) som indeholder både data og operationer til bearbejdning af dataene. Fx. omfatter begrebet Bankkonto ikke blot data (saldo, rentefod mv.), men også de operationer, der kan udføres på en bankkonto (indsæt, hæv, beregn rente mv.). De fleste systemudviklingsmetoder focusere på enten data (fx. JSP) eller funktioner (fx. Yourdon SA/SD). Objektorientering søger at beskrive data og funktioner under ét og giver hermed mere forståelige modeller. Dvs. programkoden bliver en bedre model af virkeligheden, og dermed lettere gennemskueligt. Dataabstraktion Det har vist sig, at dataobjekter betragtet på et vist logisk niveau er langt mere stabile end funktioner. Dataobjekterne i problemområdet (kunde, konto mv.) forbliver stort set de samme, mens krav til funktionalitet ændres ustandseligt. Objektorientering tager udgangspunkt i dataobjekter og beskriver dem abstrakt, dvs. gennem krav til deres tilknyttede operationer.
Klassebegrebet En klasse er en beskrivelse af en række objekter med fælles egenskaber. Man kan sammenligne en klasse med en record-definition, blot er der tilføjet operationer i form af procedurer/funktioner til bearbejding af objekternes data. Ved at anvende klasser til at opbygge de moduler, som et program skal bestå af, tilgodeses modelaspektet. Moduler i programmet (= klasser) svarer direkte til begreber i problemområdet. Ved at indkapsle data i objekter og kun tilgå dem via de tilknyttede operationer understøtter klasser dataabstraktion. Klasser er således den helt centrale konstruktion i objektorienteret udvikling mht. opnåelse af gennemskuelighed og stabilitet. 3 class BankKonto private public Rentefod, Saldo: Real Ejer: #Kunde Opret( - ): --- DispBeløb: return Saldo Indsæt( - ): --- Hæv( - ): --- -- andre operationer -- definition af datafelter -- reference til et objekt af type Kunde Figur 1: Beskrivelse af klassen BankKonto i en til lejligheden opfundet notation. Åben/lukket-princip Isoleret betragtet er en klasse et lukket modul: data er indkapslet bag operationer, som kan anvendes udelukkende udfra kendskab til deres interface (parameterlister og funktionelle specifikationer), men vi ønsker jo også, at vores moduler skal være åbne over ændringer, udvidelser og anvendelse i andre sammenhænge end de oprindelige. Løsningen herpå er nedarvning (og polymorfi). Nedarvning Nye klasser kan dannes som specialiseringer af gamle klasser. Nye egenskaber kan tilføjes, og gamle kan omdefineres. Fx. hvis vi har en klasse BankKonto, som bla. indeholder datafelterne Ejer, Saldo og Rentefod og bla. operationen DispBeløb, som returnerer Saldo. Vi kan danne en ny klasse ØkonomiKonto, som en specialicering af BankKonto ved at definerere ØkonomiKonto, som en arving til BankKonto. ØkonomiKonto har hermed automatisk alle BankKonto's egenskaber (data og operationer). ØkonomiKonto adskiller sig imidlertid fra BankKonto ved at have tilknyttet en kredit på fx. 10000 kr. I ØkonomiKonto tilføjes derfor datafeltet Max, og operationen DispBeløb omdefineres, så der nu returneres Saldo + Max. På tilsvarende vis kan andre kontotyper defineres udfra eksisterende klasser. Polymorfi Sammen med nedarvning understøtter polymorfi mulighederne for at udvide/ændre programmer. Polymorfi indebærer, at referencer til et objekt af en given klasse kan erstattes af referencer til et objekt af en klasse, som er arving til den oprindelige. Da en arving er en
4 specialisering af sin forfader, så har arvingen også alle forfaderens egenskaber (data og class ØkonomiKonto inherit BankKonto -- ØkonomiKonto er arving til BankKonto. private public Max: Real DispBeløb: return Saldo + Max -- datafelterne RenteFod og Saldo arves og skal ikke defineres igen. Ligeledes for Ejer. -- DispBeløb omdefineres, øvrige operationer arves. -- evt. andre operationer specielle for ØkonomiKonto Figur 2: Beskrivelse af klassen ØkonomiKonto som arving til BankKonto. Objekter tilhørende klasse ØkonomiKonto har alle egenskaber defineret i BankKonto og alle defineret i ØkonomiKonto. operationer - nogle evt. omdefinerede). Hermed kan arvingen udføre samme operationer som forfaderen, men på sin egen måde. I bankeksemplet betyder dette, at man kan kalde DispBeløb og få det rigtige svar uanset om, det er et objekt af type BankKonto eller et objekt af typen ØkonomiKonto, man refererer til. Hermed kan rutiner, som er skrevet til at bearbejde objekter af klassen BankKonto, også håndtere objekter af typen ØkonomiKonto, men endnu vigtigere også objekter af nye klasser, som måtte blive defineret i fremtiden, blot de er arvinge til BankKonto og har en (for dem korrekt) version af operationen DispBeløb. 4. Afslutning Sammenfattende kan det siges, at - software-udviklingens største udfordring er at skabe systemer, der er gennemskuelige, stabile overfor nye krav til systemets funktionalitet og systemer, hvis komponenter er åbne overfor modifikationer, så de kan indgå i nye anvendelser. - objektorientering prøver at møde denne udfordring ved at beskrive virkeligheden som objekter, der indeholder både data og tilknyttet funktionalitet. Udgangspunktet herfor er dataabstraktion, idet dataobjekter på et vist logisk niveau er langt mere stabile end funktioner. Nedarvning og polymorfi understøtter udviklingen af fleksibile software-komponenter, herigennem skabes modificérbart software, og mulighederne for genbrug af software-komponenter styrkes.
Det skal dog nævnes, at de objektorienterede metoder endnu ikke er færdigudviklede, der er stadig ubesvarede spørgsmål, metoderne og værktøjerne mangler eller er ufuldstændige, men tendensen er klar: Svarene kommer hurtigere og hurtigere, metoder og værktøjer forbedres hele tiden, og der gøres stadig flere erfaringer med praktisk anvendelse af objektorientering. Objektorientering ser ud til at være kommet for at blive og er det hidtil bedste bud på en løsning på software-krisen. Dette har været en meget kortfattet og postulerende opridsning af nogle grundlæggende forhold og begreber, men der findes efterhånden en righoldig litteratur, som uddyber, forklarer og argumenterer grundigere for mine påstande, og jeg må i denne sammenhæng nøjes med at henvise evt. interesserede til denne litteratur. 5