Danish University Colleges
Objektorientering = Programkvalitet ?
Nordbjerg, Finn Ebertsen
Published in:
Prosabladet. De it-professionelles fagblad
Publication date:
1993
Document Version
Tidlig version også kaldet pre-print Link to publication
Citation for pulished version (APA):
Nordbjerg, F. E. (1993). Objektorientering = Programkvalitet ? Prosabladet. De it-professionelles fagblad, (4).
General rights
Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.
• Users may download and print one copy of any publication from the public portal for the purpose of private study or research.
• You may not further distribute the material or use it for any profit-making activity or commercial gain • You may freely distribute the URL identifying the publication in the public portal
Download policy
If you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediately and investigate your claim.
Download date: 04. Jul. 2022
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 universitets- kredse 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. 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.
class BankKonto
private
Rentefod, Saldo: Real -- definition af datafelter
Ejer: #Kunde -- reference til et objekt af type Kunde public
Opret( - ): ---
DispBeløb: return Saldo Indsæt( - ): ---
Hæv( - ): ---
-- andre operationer
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
specialisering af sin forfader, så har arvingen også alle forfaderens egenskaber (data og
class ØkonomiKonto inherit BankKonto
-- ØkonomiKonto er arving til BankKonto.
private
Max: Real -- datafelterne RenteFod og Saldo arves og skal ikke defineres igen. Ligeledes for Ejer.
public
DispBeløb: return Saldo + Max -- 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 virkelig- heden 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.
