Kurt Nørmark ©
Department of Computer Science, Aalborg University, Denmark


September 2001

Abstract Next lecture Index References Contents

I denne lektion introducerer vi objekt-orienteret programmering. Dette inkluderer begreberne indkapsling (encapsulation) og information hiding. Vi starter med ideen om data abstraktion og abstrakte datatyper. Som en kontrast til programmeringsstilen og metoden i objekt-orienteret programmering ser vi på såkaldt struktureret programmering, som dyrkes af mange programmører i det imperative paradigme. Denne lektion er uafhængig af programmeringssprog. Vi indfører de objekt-orienterede begreber i relation til Java i en senere lektion.

Program: Et simpelt (hoved)program, som iterativt læser en konto og dernæst udfører en transaktion på den. De fremhævede dele af programmet er pseudoprogram, som forfines herefter. Vi ser hovedprogrammet af et meget simpelt bank program, som i en løkke indlæser en konto, og dernæst udfører en bestemt transaktion på denne. Vi kan sige, at vi ser på toppen af dette program. Samtidig er det vigtigt at bemærke, at det typisk er her vi starter udviklingen af programmet. Når et program udvikles top-down startes med de overordnede dele af programmet, og dele deraf forfines trinvis, indtil alle detaljer er fuldt ud implementeret. De fremhævede dele af programmet er pseudoprogram (kommentarer), som vi vil forfine (videreudvikle) på de følgende sider.

Program Minibank; Type Kontotype = (checkKonto, aktionærKonto, pensionsKonto, gevinstKonto); Bankkonto typedefinitioner; Procedure som gennemfører transaktioner; Function LaesKontotype: KontoType; begin ... end; begin while not fyraften do begin kt := LaesKontoType; udfør en transaktion kontotype kt end end.

Eksempel: Struktureret programmering (2) Slide Note Contents Index References Speak

Program: Vi ser en del af forfiningen af 'Bankkonto typedefinitioner'. Tilsvarende records skal gives for de andre kontotyper.

checkKonto = record id: KontoId; balance: Kroner; renteSats: Real; antalUdnyttedeChecks: Integer; end

Program: Vi viser her den centrale og overordnede transaktions procedure. Denne procedure forfiner altså 'Procedure som gennemfører transaktioner'. Afhængig af kontotype kaldes en mere specifik transaktionsprocedure, som er kontotype specifik

procedure transaktion(kt: Kontotype); Type TransaktionsType = (opret, hæve, indsætte, tilskrivRente, clearCheck, nedlaeg); Procedurer for forskellige typer af transaktioner; begin case kt of checkKonto: checkKontoTransaktion; aktionærKonto: aktionærKontoTransaktion; pensionsKonto: pensionsKontoTransakton; gevinstKonto: gevinstKontoTransaktion; end; end (* transaktion *)

Eksempel: Struktureret programmering (3) Slide Note Contents Index References Speak

Program: I denne procedure processerer vi en checkkonto. Vi ser igen, at vi skal definere procedurer til hhv. oprettelse, hævning, indsættelse, mv. på checkkontoen. De enkelte transaktionsprocedurer antages igen at være lokale procedurer til denne procedure.

procedure checkkontoTransaktion; var ck: checkKonto; forskellige transaktions procedurer på checkKonto function LaesTransaktionsType: TransaktionsType; begin ... end; procedure hentCheckKonto(var k: CheckKonto); begin ... end; procedure GemCheckKonto(var k: CheckKonto); begin ... end; begin hentCheckKonto(ck); tt := LaesTransaktionsType; case tt of opret: opretCheckKonto(ck); hæve: hæveCheckKonto(ck); indsætte: indsætteCheckKonto(ck); tilskrivRente: tilskrivRenteCheckKonto(ck); clearCheck: clearEnCheck(ck); nedlaeg: nedlaegCheckKonto(ck); end; gemCheckKonto(ck); end (* checkkontoTransaktion *)

Program: Minibank programmet i sammenhæng. Vi linker her til en udgave af programmet, hvor alle fragmenterne er sat sammen. Man skal især lægge mærke til, hvordan procedurerne naturligt indlejres i hinanden. Bemærk også, at betydelige dele af programmet kun er skitseret.

Oversigt over bankkonto operationer Slide Note Contents Index References Speak

Table. En tabel som giver oversigt over de forskellige transaktionsprocedurer pr. kontotype

- Hæve Indsætte Tilskrive rente Oprette ... Checkkonto hæve CheckKonto indsætte CheckKonto tilskrivRente Checkkonto opret Checkkonto ... Aktionærkonto hæve AktionærKonto indsætte AktionærKonto tilskrivRente Aktionærkonto opret Aktionærkonto ... Pensionskonto hæve PensionsKonto indsætte PensionsKonto tilskrivRente Pensionskonto opret Pensionskonto ... Gevinstkonto hæve GevinstKonto indsætte GevinstKonto tilskrivRente Gevinstkonto opret Gevinstkonto ... ... ... ... ... ... ...

Med den skitserede fremgangsmåde kræves der en transaktionsprocedure pr. konto-type pr. transaktion. Dette giver et stort antal forskellige procedurer, som vist i tabellen ovenfor. Nogle af disse procedurer har sikkert lighedspunkter, som det kunne være hensigtsmæssigt at samle på ét sted. Hvis man ønsker at opretholde kontotype definitionerne som hver sin record type, er det nødvendigt at have en procedure for hvert felt i tabellen. Procedurerne er struktureret således, at hver række af procedurer er lokale til den bank-konto type specifikke transaktionsprocedure. Man kan i Pascal arrangere tingene mere hensigtsmæssigt, nemlig ved at definere én type, som dækker alle konto-typer. En sådan record type skal have afdelinger med felter, der er specifikke for den enkelte konto-type. Sådanne records kaldes variant-records

References Variant records: Koffman afsnit 12.6 Eksempel: Objekt-orienteret programmering

Sidst i denne lektion ser vi på en objekt-orienteret version af dette eksempel

The concept objekt: Et objekt er en indkapsling af data. Et objekt har identitet, tilstand og adfærd.		Et objekt er en samlet indkapsling af en række data bestanddele. Ydermere bestræber vi os på at skabe disciplineret tilgang til disse data gennem en grænseflade af operationer. Vi kan opfatte operationerne som en integreret del af objektet. Nogle af dataene har måske kun begrænset synlighed og brugbarhed uden for objektet. Et objekt har identitet, hvilket vil sige at objektet er mere end blot summen af delene. Vi kan derfor se forskel på to objekter med samme databestanddele. Objektets tilstand bæres af de enkelte databestanddele, som typisk kan læses og ændres via operationer (metoder). Operationerne beskriver objektets adfærd. Vi vender herunder tilbage til både grænseflader og objekt-identitet.
The concept abstrakt datatype: Et objekt er en instans af en abstrakt datatype.		Abstrakte datatyper er datatyper, hvori værdierne tilgås via en mængde af operationer. Alternativet (for konkrete datatyper) er at manipulere værdierne direkte, som de er repræsenteret. Dette skaber store bindinger mellem data-anvendelsen og data-definitionen. Betegnelsen værdi og objekt anvendes her synonymt, omend det ikke altid er tilfældet når vi har med objekt-orienteret programmering at gøre. Mere om dette i en senere lektion.
The concept klasse: En abstrakt datatype programmeres ved brug af en klasse.		I de fleste objekt-orienterede programmeringssprog skabes objekter ved at instantiere en klasse. Abstrakte datatyper programmeres altså via klasser. Klasser og typer forholder sig til hinanden ligesom objekter og værdier. Typer og værdier er betegnelser, som stammer fra den matematiske del af faget. Klasser er en programmeringssproglig konstruktion. Og objekter er instanser af klasser, som findes på programmets køretidspunkt. Man kan også forestille sig at objekter skabes ved at kopiere allerede eksisterende objekter. Her er vi dog stadig efterladt med spørgsmålet om, hvor det første objekt af en bestemt type kommer fra.

Figure. Otte data enheder til venstre organiseres i to objekter til højre. Rammen omkring objekterne symboliserer indkapslingen og delvist objekternes identitet.

Abstrakte datatyper Slide Note Contents Index References Speak

Betegnelsen 'abstrakte datatyper' stammer i overvejende grad fra den matematisk/teoretiske del af datalogi. Når vi arbejder med abstrakte datatyper ønsker vi at afskærme os fra viden om den konkrete og detaljerede datarepræsentation. Alle aflæsninger og ændringer af data sker gennem en mængde af operationer. Abstrakte datatyper udgør en af grundpillerne i objekt-orienteret programmering.

The concept abstrakt datatype: En abstrakt datatype er en mængde af værdier eller objekter samt en tilhørende mængde af operationer på disse

En datatype defineres ofte som en mængde af værdier. I en abstrakt datatype fokuserer vi ikke på disse værdier's datarepræsentation, men på hvordan vi manipulerer (opretter og ændrer) på disse. Dette sker gennem operationerne.

Eksempel. En mængde af bankkonti med operationer til indsættelse, hævning, rentetilskrivning og pengeoverførsel er et hverdagseksempel på en abstrakt datatype

Programmeringsmæssigt er det en vigtig observation, at brugen af en abstrakt datatype bankkonto ikke inkluderer detaljer om hvordan bankkonto data lagres og repræsenteres. Når vi på et tidspunkt skal programmere en bankkonto har vi frie hænder til at vælge en hensigtsmæssig repræsentation. Valget påvirke ikke grænsefladen af den abstrakte datatype, men kun typens implementation.

 

Eksempel. Mængden af heltal med de velkendte aritmetiske operationer er et matematisk eksempel på en abstrakt datatype

Vi ved alle, at tal i en computer repræsenteres i det binære talsystem. Men vi er heldigvis også vant til ikke at tænke på disse detaljer, når vi arbejder med tal. Vi fristes f.eks. aldrig til at aflæse 'mindst betydende bit i et heltal'; Vi anvender en operation, som aflæser hvorvidt tallet er lige eller ulige. Tallenes nytte for os afspejler sig altså i de operationer, som vi kan udføre på dem. Vi kan med rette sige, at vi tænker på heltal som en abstrakt datatype. Lad dette være et forbillede for, hvordan vi fremover ønsker at programmere i det objekt-orienterede paradigme

 

En abstrakt datatype afskærmer og beskytter den konkrete repræsentation af data til fordel for en datatilgang på et højere abstraktionsniveau.

Indkapsling, information hiding og grænseflade Slide Note Contents Index References Speak

Som allerede omtalt er indkapsling og information hiding helt centralt. Her studerer vi disse emner i yderligere detalje

Ofte indkapsles alle data på en sådan måde, at de er usynlige for objektets omverden Data tilgås således konsekvent via operationer

Figure. Et objekt A med skjult information og grænseflade til omverdenen. De tre elementer (data eller operationer) tegnet på kanten af objektet symboliserer grænsefladen. De to elementer inden i objekter er skjult for omverdenen.

Hvad objektets omverden ikke kan se, kan omverdenen ikke gøre sig afhængig af. Objekt indkapslingen udgør en brandmur mellem objektet og dets omverden Objektets skjulte egenskaber kan lettere programmeres om end de synlige dele af klassen. Repræsentations uafhængighed udtrykker ideen om at gøre et program uafhængig af den valgte datarepræsentation Når vi taler om at ændre data ovenfor tænker vi på programændringer, som indebærer forandringer i den måde vi repræsentere data i en klasse. Hvis alle data er skjult for omverdenen, kan ingen programdele i klassens omverden gøre sig direkte afhængig af disse data. Det er derfor at vi har lettere ved at modificere disse, uden at alle hjørner og kroge i klassens omverden også skal modificeres. For store programmer, er dette nogle meget væsentlige iagttagelser.

Records Klasser Kun data er indkapslede i recorden Både operationer og data er indkapslede i klassen Normalt er der ingen begrænsninger på synlighed af felterne Normalt er kun operationerne synlige udaf til

Klasser generaliserer record begrebet

En konventionel record Slide Note Contents Index References Speak

I forlængelse af ovenstående studerer vi nu hvordan man ofte bruger records som parametre til procedurer

Program: Vi ser en record R med tre datafelter. Endvidere ser vi to procedurer op1 og op2, som opererer på en R record via en parameter af record typen.

type R = record f1: T1; f2: T2; f3: T3 end ... procedure op1(p: R) begin ... end procedure op2(q: R; x: int) begin ... end

En klasse Slide Note Contents Index References Speak

Vi illustrerer nu hvordan det forrige eksempel ser ud når vi har introduceret klassebegrebet

Program: I forhold til forrige program ser vi, at procedurerne nu er flyttet ind i klassen. Vi ser endvidere at operationerne ikke længere tager en R parameter. I og med at vi har flyttet procedurerne ind i klassen arbejder operationerne nu på en instans af klassen. Vi kan sige, at en instans af klassen altid vil udgøre en implicit første parameter til klassens operationer.

class R f1: T1; f2: T2; f3: T3; operation op1 begin .. end; operation op2 (x: int) begin .. end end

Lidt senere i lektionen vil vi se at vi anvender en særlig syntaks - dot notation - til at kalde en operation på et objekt af klassen R.

Klasser Objekter En klasse udgør en beskrivelse af fælles egenskaber for en række objekter Et objekt repræsenterer egenskaber af en bestemt ting - konkret eller abstrakt En klasse modsvarer et begreb Et objekt modsvarer et fænomen, som er dækket af begrebet En klasse er en del af et program Et objekt er data, og en del af programmets udførelse

Instantiering af klasser Slide Note Contents Index References Speak

Vi vil nu se nærmere på, hvordan vi kan lave objekter ud fra klassen. Vi opfatter i den forbindelse klassen som en forskrift ud fra hvilken vi kan konstruere et objekt

Klasse instantiering er mekanismen hvormed objekter oprettes ud fra klassen Enhver form for instantiering involverer allokering af lager til objektet

Statisk instantiering Dynamisk instantiering Foreskrives i programmets erklæringsdel Foreskrives i programmets handlingsdel En statisk instans skabes implicit sammen med det omkringliggende objekt En dynamisk instans skabes eksplicit gennem en særlig kommando

Det er her værd at bemærke at de data vi arbejdede med i Pascal på basisuddannelsen alle har været statisk instantierede. Simple data såvel som datastrukturer (arrays, records og til en vis grad filer) blev oprettet og allokeret i variabelerklæringer. Dynamisk instantierede data findes også i Pascal. Sådanne data er tæt forbundne til pointer begrebet.

Objekt initialisering er mekanismen hvormed objektet tilskrives en fornuftig og meningsfuld starttilstand Objekt initialisering er det naturlige næste skridt efter instantiering. Det er en stor synd ikke at tilskrive et nyt objekt en fornuftig starttilstand. Vi kan sige, at et nyfødt objekter fortjener en god start på tilværelsen.

Interaktion mellem objekter sker ved at sende beskeder via etablerede relationer En besked til et objekt aktiverer en operation

Et objekt O1 interagerer med et andet objekt O2 ved at kalde en operation i O2 objektets klientgrænseflade. I billedsprog siger vi at objekt O1 sender en besked til objekt O2. Forudsætningen for at objekter kan kommunikere er at objekterne er relaterede til hinanden Et kald af en operation svarer til et procedurekald, hvor objekt-modtageren er en særlig vigtig parameter Besked afsending - message passing - stammer fra Smalltalk, som i høj grad populariserede den objekt-orienterede tankegang sidst i 70'erne og først i 80'erne Objekternes indbyrdes relationer er væsentlige emner i både systemanalyse og systemdesign. Vi taler om forskellige former for objekt relationer: associationer og aggregeringer. I forbindelse med programmeringen kan sådanne relationer realiseres på mange forskellige måder, f.eks. som pointere gennem objekter og som tabeller der holder styr på relationer mellem par af objekter. Modtager objektets særstatus afspejles af en særlig syntaks, hvor modtager objektet stilles foran selve procedurekaldet. Vi taler om dot-notation.

Konventionelt procedurekald Slide Note Contents Index References Speak

Vi ser nu på konventionelle procedurekald som en kontrast til kald af operationer på objekter

Program: Proceduren P har to parametre af hhv. typen C og D. Vi ser et kald af P med to dataobjekter af disse typer

procedure P (x: C; y: D); begin ... end; ... var a: C; b: D; begin P(a, b) end

Kald af en operation Slide Note Contents Index References Speak

Vi ser her på et kald af en operation på et objekt.

Program: Operationen P i klassen C har kun én parameter. Endvidere kan man tænke på klassen, hvori operationen bor, som værende en implicit parameter. Dette ser vi i kaldet, hvor P aktiveres på et C objekt, nemlig a. Læg mærke til vores brug af dot notation.

class C operation P (x: D); ... end ... var a: C; b: D; begin a.P(b) end

The concept fænomen: Et fænomen er en ting i den virkelige (eller 'tænkte') verden, som har individuel eksistens		Et fænomen kan være en konkret, fysisk ting. Et eksempel på en ting er det bestemte tastatur, som jeg betjener mig af for at skrive disse linier. Et fænomen kan også være mindre fysisk tilstedeværende, såsom en bestemt matematisk struktur, eksempelvis en trekant med bestemte sider, vinkler og placering i et plan.
The concept begreb: Et begreb er en generaliseret ide, afledt fra en samling af fænomener, og baseret på viden om fælles egenskaber af disse fænomener		Et begreb er en mere abstrakt størrelse end et fænomen. Dog er begreber kendt fra vores hverdag. Vi taler om tastaturer og trekanter i almindelighed; med dette er vi optaget af disse begrebers egenskaber, i modsætning til en ganske bestemt ting's egenskaber.

Karakteristika ved et begreb Begrebsnavn Intensionen: Mængden af egenskaber, der karakteriserer begrebet Extensionen: Mængden af fænomener, der er dækket af begrebet

Exercise 1.1. Fænomener kontra begreber

Denne opgave har til formål at blive god til at skelne mellem begreber og fænomener (samt mellem klasser og objekter når vi taler programmering). Bestem hvert af de følgende som enten et fænomen (objekt) eller et begreb (klasse): En dør Døren til jeres grupperum Lærebogen, som anvendes på dette kursus Dit eksemplar af lærerbogen, på dette kursus Introduktionsforelæsningen på dette kursus En hjælpelærer Danmark 7 Mængden af alle studerende som følger dette kursus i et bestemt semester Studerende I de tilfælde, hvor der er tale om fænomener, skal I endvidere identificere det begreb som dækker fænomenet.

Klassificering og eksemplificering Slide Note Contents Index References Speak

På denne side vil vi se på sammenhængene mellem begreber og fænomener.

The concept klassificering: Klassificering udtrykker det begrebslige tilhørsforhold af et fænomen		Klassificering udtrykker en sammenhæng mellem fænomener og det begreb, som dækker fænomenerne. Der vil typisk være mange fænomener der afbildes på det samme begreb.
The concept eksemplificering: Eksemplificering udtrykker et fænomen, som er dækket af begrebet		Som navnet antyder udtrykker en eksempliciering et eksempel på et fænomen i et begreb. Der vil typisk være mange mulige eksempler.

Figure. Figuren viser sammenhængene mellem et begreb og et fænomen. Klassificering/eksemplificering er let at få øje på blandt begreber og fænomener i vores hverdag. Begrebet 'gravhund' kan have 'Fido' og 'King' som eksempler; omvendt klassificerer 'gravhund' de nævnte to eksempler på hunde.

Reference A Conceptual Framework for Programming Languages: Jørgen Lindskov Knudsen og Kristine Stougaard Thomsen, Datalogisk Afdeling, Aarhus Universitet, PB-192, April 1985.

Aggregering og dekomponering Slide Note Contents Index References Speak

Med introduktionen af objekt-orienteret programmering fokuserer vi i udpræget grad på objekters egenskaber. Da vi ofte har mange objekter af samme slags er der meget at hente, hvis vi under ét - og på ét fælles sted - kan beskrive alle objekters fælles egenskaber. De fælles egenskaber svarer til de begrebslige egenskaber. Derfor er det meget relevant for objekt-orienteret programmering at studere hvordan vi danner nye begreber ud fra eksisterende begreber

Hvordan danner man nye begreber ud fra eksisterende begreber?

The concept aggregering: Aggregering samler et antal bestanddele til en helhed		Med aggregering danner vi et nyt helhedsbegreb ud af et antal begreber for de dele som indgår.
The concept dekomponering: Dekomponering splitter en helhed i et antal dele		Med dekomponering splitter vi et helhedsbegreb i de begreber, hvoraf helheden er lavet

Figure. Aggregering samler et antal begreber i et nyt begreb. Dekomponering løsriver allerede samlede begreber i dets bestanddele.

Generalisering og specialisering Slide Note Contents Index References Speak

I forlængelse af forrige side ser vi her på en anden måde at lave et begreb ud fra et eksisterende: Specialisering, og modsat rettet generalisering.

The concept generalisering: Generalisering danner et bredere begreb fra et smallere		Generalisering er udtryk for en begrebsdannelse, hvor man tager udgangspunkt i et eksisterende begreb som gøres bredere.
The concept specialisering: Specialisering danner et smallere begreb fra et bredere		Specialisering repræsenterer en begrebsdannelse som er modsat rettet af generalisering

Figure. Et generaliseret begreb betegner et bredere dækkende begreb end det specialiserede begreb.

Exercise 1.2. Litteraturbegreber

Beskriv og tegn et generaliserings/specialiserings hierarki for de forskellige typer af bøger, rapporter og tidsskrifter, der findes på et fagbibliotek, såsom AUB. Skitser dataegenskaberne af ovenstående begreber, samt hvilke operationer, der bør være, hvis vi skal bruge hierarkiet til at lave et katalogsystem til søgning ol. Inkluder endvidere begrebet `artikel' (som vi kender det fra bl.a. tidsskrifter), og diskuter, hvordan `artikel' forholder sig til `tidsskrift'. Diskuter tilsidst et begreb, der dækker samlingen af litteratur, som findes på et fagbibliotek. Hvordan forholder dette begreb sig til ovenstående begreber?

Exercise 1.3. Time concepts

Describe and draw the specialization/generalization hierarchy of concepts associated with points in time and time intervals. As an inpiration we can mention such concepts as date, time, day, week, month, and year. Is there a common generalization of points in time and time interval? Is there an aggregation relationship between the two concepts? Describe some useful properties (operations) of the two concepts. What is the relationships between the designed concept hierarchy and the calendar concept?

Ekstensionen af et specialiseret begreb er en delmængde af ekstensionen af det mere generelle begreb. Intensionen af det specialiserede begreb udvides typisk med nye egenskaber; det kan også forekomme, at eksisterende egenskaber redefineres (pålægges bånd) når man beskriver et specialiseret begreb.

Eksempler på begrebsdannelse Slide Note Contents Index References Speak

Vi vil nu se på hverdagseksempler på aggregering og specialisering

Begrebet 'flyvemaskine' er aggregeret af begreberne Cockpit Krop Haleparti Vinge Motor Et begreb hvor vi ser på en række bestanddele af begrebet.

Figure. Et begrebshierarki hvor vi ser en række specialiseringer af begrebet befordringsmiddel. Bemærk at alle niveauer i hierarkiet viser begreber - ikke fænomener.

Figure. Den naturlige generalisering/specialisering af bankkontobegreber er et godt udgangspunkt for objekt-orienteret udvikling af minibank. På bank-konto niveau kan vi beskrive fælles egenskaber af alle bankkonti, uanset specialisering.

Fælles egenskaber af alle bankkonti beskrives på det generelle niveau Egenskaber af de specialiserede bankkonti beskrives på de specialiserede niveauer

Reference Eksempel: Struktureret programmering

Eksempel: OOP (2) Slide Note Contents Index References Speak

Efter på en overordnet måde at have set på generaliserings/specialiserings hierarkiet for bankkonto klasser skitserer vi her lidt mere detaljeret programmet for to af klasserne.

Program: Den generelle bankkonto klasse. Vi ser de to private variable rentesats og balance, som beskriver tilstanden af en generel bankkonto

Class Bank-konto private rentesats: Real; private balance: Kroner public balance(): Kroner public opret (init-beløb: Kroner) public hæv (beløb: Kroner) public indsæt (beløb: Kroner) public tilskriv-rente() end Bank-konto

Program: Et eksempel på en specialisering af bankkonto. Bemærk at vi re-definerer operationen tilskriv-rente, og vi har tilføjet de nye operationer clear-check og antal-udskrevne-checks i forhold til den generelle bankkonto klasse. Der er også kommet en ny instansvariabel, antal-udskrevne-checks. I nogle sprog tillader vi at instansvariable og operationer (metoder) har samme navn; I andre er dette ikke tilladt.

Class Check-konto : Bank-konto private antal-udskrevne-checks: integer public antal-udskrevne-checks(): integer public tilskriv-rente () public clear-check(beløb: kroner) end Check-konto

Hver af typerne, som indgår i klassehierarkiet, beskrives hvad angår offentlige operationer, og operationerne implementeres. På denne slide er implementationen af operationerne hverken vist eller antydet. Der er benyttet en pseudo-syntax for abstrakte datatyper, som ikke er en del af noget programmeringssprog. Det eneste formål med denne side er at illustrere principperne i objekt-orienteret udvikling, som et modstykke til den allerede viste top-down udvikling af mini-bank programmet.

Eksempel: OOP (3) Slide Note Contents Index References Speak

Vi slutter af med at vise et muligt (hoved)program, som udnytter de bankkonto klasser, der er vist ovenfor.

Program: Den væsentlige observation i dette program er at kontoen K kan være af en vilkårlig bankkonto type, f.eks. en checkkonto eller en pensionskonto. Afhængig af typen bliver 'den rigtige og relevante' operation kaldt i case kontrolstrukturen. Et særligt godt eksempel på dette er rentetilskrivning, som kan følge forskellige regler for checkkonti og mere generelle konti. Dette er et væsentligt aspekt af objekt-orienteret programmering, som kaldes 'dynamisk binding'. Vi har meget mere at sige om dette, når vi kommer til lektionen om nedarvning.

program mini-bank-main-program; var K: Bank-konto begin while not fyraften do begin indlæs en bank-konto K; indlæs en transaktions-type TT; case TT of opret: instantiering af et nyt bank-konto objekt; hæve: indlæs beløb B; K.hæv(B); indsætte: indlæs beløb C; K.indsæt(C); tilskriv-rente: K.tilskriv-rente; clear-check: indlæs beløb D; K.clear-check(D) nedlæg: nedlæg bank-konto instans; end end end.

Reference Dynamisk binding

Programstruktur: Efter data eller funktion Slide Note Contents Index References Speak

Vi diskuterer nu forskellige svagheder ved 'top down programudvikling', som vi jo indledte med i denne lektion. Dette benyttes som overgangen til en anden programudviklingsprocess, hvor vi i langt højere grad ønsker at udvikle programmet 'bottom up'.

Hvilke handlinger udfører programmet kontra Hvad udfører programmet handlinger på?

Top-down udvikling af et program afspejler trinvis nedbrydning af et problem i mindre delproblemer og er som sådan med til at nedbringe kompleksiteten i problemløsningen. En strukturering af et program efter funktionalitet er mindre stabil end en strukturering efter data 'Rigtige systemer' har ingen top Top-down udvikling og strukturering efter funktion virker hæmmende på udvikling af genbrugelige programkomponenter.

Med objekt-orienteret programmering går vi efter bottom-up udvikling, strukturering med udgangspunkt i data, og genbrug af programkomponenter

Collected references Contents Index

Eksempel: Objekt-orienteret programmering Variant records: Koffman afsnit 12.6 A Conceptual Framework for Programming Languages: Jørgen Lindskov Knudsen og Kristine Stougaard Thomsen, Datalogisk Afdeling, Aarhus Universitet, PB-192, April 1985. Eksempel: Struktureret programmering Dynamisk binding

Chapter 1: Introduktion til objekt-orienteret programmering
Course home     Author home     About producing this web     Previous lecture (top)     Next lecture (top)     Previous lecture (bund)     Next lecture (bund)     
Generated: March 31, 2008, 12:07:55