Introductie Object-Georiënteerd Programmeren

CompuChip

Elke programmeur heeft wel een koffiezetapparaat op kantoor staan om wakker te blijven tijdens lange Delphi-nachten. Bij iedereen ziet het koffiezetapparaat er anders uit. Sommigen hebben zo'n duootje voor één of twee kopjes, anderen hebben een machine waar koffie, espresso of cappuccino uitkomt, weer anderen hebben een Philips Senseo, maar het basisidee van het koffiezetapparaat blijft hetzelfde. Aan de bovenkant doe je er water en koffiepoeder (of –zakjes, of wat de fabrikant dan ook heeft vastgelegd), je zet een kopje eronder en aan de onderkant komt er koffie uit. Niets minder, maar ook niets meer.

Je kan je afvragen waarom geïnvesteerd wordt in koffiezetapparaten. Dat is vrij logisch: je kan toch ook zélf een filtertje te nemen, koffie erin doen, water koken, een kopje eronder zetten, het water door het filter gieten, en dat twintig keer per dag, maar waarom zou je niet de moeite nemen om even naar de winkel te gaan en een machientje te kopen die het tien keer sneller kan (niet getest)?

Tot hier toe lijkt het me allemaal vrij logisch. In werkelijkheid wordt het koffiezetapparaat (en andere dingen) gebruikt zonder erbij na te denken. Maar diezelfde programmeurs zijn vaak in hun programma's lang bezig om het wiel opnieuw uit te vinden. Waarom? Waarschijnlijk omdat ze nog nooit van OO gehoord hebben, of niet weten wat het is, of denken dat het te ingewikkeld is.

Wat is OO dan?

OO(P) staat voor Object-Oriented (Programming) oftewel Object Georiënteerd Programmeren. Bij deze vorm van programmeren wordt gebruik gemaakt van klassen en objecten. Door OO te programmeren wordt een programma vaak overzichtelijker, omdat het meer structuur heeft en ook beter gespiegeld kan worden aan de buitenwereld. Bijvoorbeeld: een simulatie van een alarmsysteem is beter te begrijpen in termen van huis, ramen, deuren, sensoren dan variabelen, arrays en functies. Om een systeem uit te breiden met bijvoorbeeld een nieuwe sensor hoeft in een OO-programma maar weinig te gebeuren aangezien alle sensoren in feite hetzelfde zijn (overerving) maar toch zijn de mogelijkheden oneindig door de polymorfie. Ook voor andere programmeurs biedt het voordelen om object-geörienteerd te programmeren, namelijk inkapseling. Hiermee zijn meteen de drie basisbegrippen van OOP gevallen, die ik hierna zal uitleggen. Ze zijn eigenlijk al aan bod gekomen in het voorbeeld van het koffiezetapparaat...

De drie pijlers van OO

Inkapseling

Bij OOP wordt gebruik gemaakt van klassen (classes) en objecten (de terminologie is op dit punt wat verwarrend; officieel is een klasse een 'abstracte' definitie en een object is een instantie van een klasse). Een klasse is een verzameling van variabelen, procedures en functies die bij elkaar hoort. De procedures en functies die bij een klasse horen noemen we methoden (methods). Dat is ook precies wat inkapseling (encapsulation) inhoudt, namelijk: dat elk object (elke klasse dus) precies zijn eigen taak heeft maar die wel uitstekend uitvoert. Waar de input vandaan komt en waar de output naar toe gaan, zal het object een worst wezen. Zo is een koffiezetapparaat alleen maar bedoeld om koffie te zetten en niet om de vloer te vegen. Een automotor is alleen voor het leveren van het vermogen. Waar de benzine vandaan komt en waar het vermogen naar toe gaat – daar heeft hij geen weet van. In dit opzicht zijn objecten de bouwstenen van een programma: los heb je er niets aan, maar samen vormen ze een hecht geheel.

Overerving

Overerving (inheritance) komt in de natuur veel voor (nageslacht erft van de ouders, honden en mensen erven bepaalde eigenschappen van zoogdieren, die weer bepaalde eigenschappen van dieren erven, enzovoorts). Ook in programma's is het een krachtig hulpmiddel. Wanneer twee objecten bijna dezelfde taken moeten uitvoeren, zijn er twee mogelijkheden:

1. Je werkt één object uit, daarna knip en plak je het andere in elkaar. Resultaat: veel duplicate code en slapeloze nachten wanneer er iets veranderd moet worden in de basisfunctionaliteit. Bij een uitbreiding herhaalt dit zich.
2. De gemeenschappelijke functionaliteit breng je onder in een basisklasse. De twee klassen erven alles van de basisklasse en alleen dat wat per klasse anders is breng je in de afgeleiden onder. Wanneer er iets veranderd moet worden pas je de basisklasse aan en de wijziging wordt in alle subklassen doorgevoerd. Heb je een nieuwe klasse nodig, leid je die gewoon van de basisklasse af en voegt alleen de extra en/of afwijkende functionaliteit toe.

Voorbeeld van overerving in de natuur.
Merk op dat elke klasse alles van zijn voorganger erft.

Polymorfie

Wanneer alleen overerving mogelijk zou zijn, had je aan OOP nog niet veel. Alle zoogdieren bewegen zich immers voort, maar allemaal op een andere manier. Gelukkig is er zoiets als polymorfie. Dit wil zeggen dat afgeleiden bepaalde functionaliteit erven, maar die op hun eigen wijze invullen (implementeren). Zo erven Hond en Mens beide spraakvermogen van Zoogdier, maar Hond blaft en Mens doet iets anders. Toch is het mogelijk om de spraakfunctionaliteit al op Zoogdierniveau te declareren. Van een willekeurig Zoogdier kan dan de .Spreek-methode worden opgeroepen — zelfs zonder dat de programmeur weet wat voor een dier het is - en ieder zoogdier zal het juiste geluid maken. Daarvoor moet Hond wel .Spreek op zijn eigen manier invullen. Of, anders gezegd: Hond moet de methode Spreek herdefiniëren (override).

PlantVoort van Hond en Mens zijn hetzelfde, maar Beweeg en Spreek worden overridden.
Mens voegt bovendien een methode Programmeer toe die niet alle Zoogdieren bezitten.

Toegang

Wanneer we een OO-systeem ontwerpen, moeten we niet alleen goed nadenken over de verschillende taken die de objecten gaan uitvoeren. Wanneer iemand met onze klassen gaat werken, of dat nu de maker zelf is of een andere programmeur, willen we zoveel mogelijk fouten voorkomen (dat is immers beter dan debuggen, nietwaar?). Daarvoor hebben we een heel krachtig hulpmiddel, namelijk de compiler. Die kan ons op de vingers tikken als we iets doen wat niet mag, al dan niet per ongeluk, zoals rechtstreeks een variabele van een instantie veranderen of een interne methode aanroepen (ik wil dat SpanStembanden(frequentie: Integer) alleen door Spreek() aangeroepen kan worden en niet rechtstreeks, bijvoorbeeld). Gelukkig geeft de compiler ons een aantal steekwoorden waarmee we kunnen aangeven wat wel en niet mag, namelijk:

public

iedereen binnen en buiten de klasse mag bij de methods en/of variabelen die hieronder staan en mag ze vrijelijk aanpassen.

private

alleen methods van deze klasse mogen bij deze methods en/of variabelen. Afgeleiden en 'buitenstaanders' mogen er niet aan prutsen.

protected

voor alles binnen deze klasse en afgeleiden ervan zijn de methods en/of variabelen hieronder vrij toegankelijk, maar voor alle anderen zijn ze afgeschermd.

En dan nu... de praktijk

Als je tot hier bent gekomen: gefeliciteerd. Het goede nieuws is dat je nu de basis onder de knie hebt. Het goede nieuws is dat we nu een praktijkvoorbeeldje gaan maken. Ik heb gekozen voor een soort PacMan-achtig spel, andere dingen die goed OO te doen zijn, zijn bijvoorbeeld een winkelsimulatie, een klantenbestand of een frisdrankautomaat.

De bedoeling van het programma

We zullen een PacMan-achtig programma gaan maken, dat sterk Object-Oriënted is. Het ideale ontwerp is volledig onafhankelijk van de gebruikersinterface en zou dus in principe in een console programma moeten kunnen compileren en draaien. Aan het eind, wanneer alle klassen af zijn, zal ik dit verwerken in een één-forms-applicatie. De bedoeling is dan de monsters te ontlopen en in twee minuten zo veel mogelijk punten te scoren. Dit is een voorbeeld van wat met de klasse gedaan kan worden.

Meteen in het diepe... de code

Wat tot nu toe besproken is, was een algemene introductie tot OOP. Nu gaan we een voorbeeld maken. De taal waarin we dat doen is – uiteraard – Delphi. Ik kan nu een lange verhandeling houden over hoe klassen gedeclareerd en geïmplementeerd worden, maar ik zelf vind het altijd prettiger om de code voorgezet te krijgen en aan de hand daarvan de kijken hoe het programma is opgebouwd.

We voegen direct een nieuwe unit (dus zonder Form) toe aan het project. In een echt project zal je waarschijnlijk tegelijk met het spel ook de UI willen schrijven, zodat je tussentijds kan testen. De aanpak van dit artikel is dus niet helemaal realistisch, maar toont wel weer een belangrijk principe: de logica is onafhankelijk van de weergave.

De interface

Ik zal eerst alle declaraties doornemen, zodat je een globaal idee hebt van de verschillende klassen en hoe die met elkaar samenhangen.

unit PacMan;

interface

uses
  Windows,
  Classes,
  ExtCtrls {TTimer},
  Graphics { TGraphic, TCanvas },
  Contnrs { TObjectList };


const rectsize: Integer = 20;
const loopInterval: Integer = 10;  // 1 / ... seconds
type TDirection = (dNone, dUp, dDown, dLeft, dRight);

type
  TFieldObject = class
    private
      FPosition: TCoord;
      FGraphic: TGraphic;
    public
      constructor Create; virtual;
      destructor Destroy; override;
      function Intersects(AIntersectsWith: TFieldObject): Boolean;
      procedure Draw(ACanvas: TCanvas);
      procedure PacmanIntersect(var Pacman: TFieldObject); virtual; abstract;
      property Position: TCoord read FPosition;
      property Graphic: TGraphic read FGraphic;
  end;

• Elk object op het veld heeft een positie en een plaatje dat getekend wordt op het veld. Hiervoor maak ik velden (Fields, vandaar de prefix F-) aan. Deze zijn private: externe objecten mogen bijvoorbeeld de positie alleen aanpassen met toestemming van het object zelf, door bijvoorbeeld Move aan te roepen.
• Objecten willen misschien wel de positie weten van een ander object. Ze moeten dus de positie wel kunnen uitlezen. Vandaar de read-only parameters onderaan de public sectie. We hadden hier ook getters (en, voor read/write properties setters) kunnen schrijven, zoals

  function GetPosition: TCoord;
  procedure SetPosition(AValue: TCoord);

  maar ik vind deze oplossing persoonlijk netter. Voor meer informatie over properties, zie ook het artikel Componentenbouw.
• De standaard TObject-destructor wordt door onze klasse opnieuw gedefiniëerd. Hiervoor moet het sleutelwoord override worden toegevoegd.
• De constructor, Intersects en Draw krijgen een zeer summiere implementatie, die alleen de algemeenste code bevat welke voor alle TFieldObjects geldt. We verwachten dan ook dat deze methods overriden gaan worden. Om dit bij voorbaat aan de compiler duidelijk te maken, voegen we het sleutelwoord virtual toe.
• LET OP: Je ziet bij PacmanIntersect een extra sleutelwoord, abstract. Dit kleine woordje heeft een belangrijke invloed. Het geeft aan dat deze method in deze klasse niet geïmplementeerd hoeft te worden, je zult deze in de implementation sectie dan ook niet terug vinden. Bovendien betekent de aanwezigheid van één of meerdere abstract methods dat de hele klasse abstract wordt. Van een abstracte klasse mag je alleen andere klassen afleiden, je mag hem niet instantiëren! Als je zou proberen

  TFieldObject.Create

  aan te roepen, krijg je een compiler waarschuwing Constructing instance of 'TFieldObject' containing abstract method 'TFieldObject.PacmanIntersect'. Bovendien is de method in alle afgeleide klassen automatisch abstract (en mag je deze dus ook niet instantiëren), tot aan de klasse waarin je hem override. Gebruik abstract zoveel mogelijk, het is een krachtig hulpmiddel om te voorkomen dat je per ongeluk abstracte objecten instantieert (zoals TZoogdier of TFieldObject) in plaats van specifieke objecten (zoals TPaard of TPacMan).

type TMovingObject = class(TFieldObject)
  private
    FDirection: TDirection;
  public
    procedure Move(); overload; virtual;
    procedure Move(ADirection: TDirection); overload; virtual;
    property Direction: TDirection read FDirection;
  end;

• Merk op dat de Move methode overloaded is. Je kan hem zonder parameters aanroepen (in welk geval het object in de richting aangegeven door FDirection zal bewegen, of met een expliciete richting van beweging.
• We hebben de abstracte methode uit TFieldObject nog niet overriden, deze klasse is dus automatisch abstract en kan niet geïnstantiëerd worden!

type TPacMan = class(TMovingObject)
  private
    FScore: Integer;
    FHitpoints: Integer;
    FIsDead: Boolean;
    procedure SetHitpoints(AValue: Integer);
  public
    constructor Create; override;
    procedure PacmanIntersect(var Pacman: TFieldObject); override;
    property IsDead: Boolean read FIsDead;
    property HitPoints: Integer read FHitpoints write SetHitpoints;
    property Score: Integer read FScore write  FScore;
  end;

type TMonster = class(TFieldObject)
  private
    FDamage: Integer;
  public
    constructor Create; override;
    procedure PacmanIntersect(var Pacman: TFieldObject); override;
  end;

type TGadget = class(TFieldObject)
  private
    FScore: Integer;
  public
    procedure PacmanIntersect(var Pacman: TFieldObject); override;
    property Score: Integer read FScore;
  end;


type TBurger = class(TGadget)
  public
    constructor Create; override;
  end;

type TWater = class(TGadget)
  public
    constructor Create; override;
  end;

type TSpel = class
  private
    FTimer: TTimer;
    FCanvas: TCanvas;
    FPacMan: TPacMan;
    FCharacters: TObjectList;
    FGadgets: TObjectList;
    FFieldCorner: TCoord;
    FWholeSecond: Integer;
    function CanMove(ACharacter: TFieldObject; ADirection: TDirection): Boolean;
    procedure GameLoop(Sender: TObject);
    function GetScore: Integer;
    constructor Create; overload;
  public
    constructor Create(const AWidth, AHeight: Integer; const ACanvas: TCanvas); overload;
    destructor Destroy; override;
    procedure Draw();
    procedure Move(ADirection: TDirection);
    property PacMan: TPacMan read FPacMan;
    property Score: Integer read GetScore;
  end;

• FTimer is een TTimer die zorgt dat de spellus continu doorlopen wordt zolang het spel loopt.
• FCanvas is een TCanvas waarop Spel de huidige spelsituatie zal tekenen. Zoals je ziet weet TSpel dus helemaal niets van een TForm of wat dan ook af, het krijgt alleen een TCanvas aangereikt en gaat er van uit dat het daarop moet tekenen.
• FPacMan is de 'hoofdpersoon': een TPacMan object.
• FCharacters en FGadgets zijn twee objectlijsten die respectievelijk de TMonster-(afgeleiden)-objecten en de TGadget-(afgeleiden)-objecten beheren.
• FFieldCorner geeft de rechteronderhoek van het scherm, oftewel: X is de breedte van FCanvas en Y is de hoogte ervan. De linkerbovenhoek is natuurlijk (0,0).
• FWholeSecond is een veld dat bijhoudt hoeveel timer-intervallen er zijn verstreken. De timer wordt namelijk enkele malen (standaard 100) per seconde uitgevoerd. De monsters moeten echter maar 1 vakje per seconde bewegen. Het gebruik van dit datalid is te zien in de GameLoop-procedure.
• CanMove is een functie die, gegeven een FieldObject en de richting waarin het wil bewegen, controleert of dit kan en True of False terug geeft.
• GameLoop is de procedure die elke 1 / loopInterval seconden wordt uitgevoerd. Dit is de main game loop, die zorgt voor het aanmaken van objecten, vergelijken en tekenen, zeg maar de Beheerder (© Marcel).
• GetScore is de getter van de Score property, die niets anders doet dan de score van het PacMan object opvragen.
• Verder maken we nog aan: een constructor en een destructor voor het aanmaken en opruimen (!) van de rotzooi, een Draw functie, een Move procedure voor Pacman en twee public properties zodat ook ánderen bij FPacMan en FScore kunnen, zij het alleen-lezen! (No object messes with TSpel's members!)

De TSpel klasse staat niet in het diagram. Deze maakt gebruik van alle klassen op de onderste rij, dus de gespecialiseerde klassen.

De implementatie

In de implementation-sectie beginnen we met het includen van Math, aangezien deze een aantal functies (voor random getallen) bevat die we willen gebruiken later. Hierna volgt de definitie van TObject.

constructor TFieldObject.Create;
begin
 inherited Create;
 FPosition.X := RandomRange(0, 19);
 FPosition.Y := RandomRange(0, 19);
 FGraphic := TBitmap.Create;
 FGraphic.Transparent := True;
end;

destructor TFieldObject.Destroy;
begin
  FGraphic.Free;
  inherited;
end;

FGraphic := TGraphic.Create;

procedure TFieldObject.Draw(ACanvas: TCanvas);
begin
 if not Assigned(FGraphic) then
  EInvalidGraphic.Create('Een TFieldObject heeft een ongeldig plaatje. Is er een LoadFromFile uitgevoerd?')
 else
  ACanvas.Draw(FPosition.X * rectsize, FPosition.Y * rectsize, FGraphic);

end;

function TFieldObject.Intersects(AIntersectsWith: TFieldObject): Boolean;
begin
 Result := (AIntersectsWith.FPosition.X = FPosition.X) and
        (AIntersectsWith.FPosition.Y = FPosition.Y);
end;

{ TMovingObject }

procedure TMovingObject.Move;
begin
 if FDirection <> dNone then
  Move(FDirection);
end;

procedure TMovingObject.Move(ADirection: TDirection);
begin
 case ADirection of
  dUp:    Dec(FPosition.Y);
  dDown:  Inc(FPosition.Y);
  dLeft:  Dec(FPosition.X);
  dRight: Inc(FPosition.X);
 end;
end;

{ TPacMan }

constructor TPacMan.Create;
begin
  inherited;
  FGraphic.LoadFromFile('pacman.bmp');
  Hitpoints := 100;
end;

procedure TPacMan.PacmanIntersect(var Pacman: TFieldObject);
begin
  // Pacman snijdt zichzelf per definitie (aangenomen dat Pacman == Self)
  // Dus: doe niets

end;

procedure TPacMan.SetHitpoints(AValue: Integer);
begin
 FHitPoints := AValue;
 FIsDead := (FHitpoints < 0);
end;

{ TMonster }
constructor TMonster.Create;
begin
  inherited;
  FDamage := 10;
  FGraphic.LoadFromFile('monster.bmp');
end;

procedure TMonster.PacmanIntersect(var Pacman: TFieldObject);
begin
  inherited;
  if PacMan is TPacMan then
   TPacMan(Pacman).Hitpoints := TPacMan(PacMan).HitPoints - FDamage;
end;

{ TGadget }
procedure TGadget.PacmanIntersect(var Pacman: TFieldObject);
begin
  if PacMan is TPacMan then
   TPacMan(Pacman).Score := TPacMan(PacMan).Score - FDamage;
end;

{ TBurger }
constructor TBurger.Create;
begin
  inherited;
  FScore := 20;
  FGraphic.LoadFromFile('burger.bmp');
end;

{ TWater }
constructor TWater.Create;
begin
  inherited;
  FScore := 10;
  FGraphic.LoadFromFile('water.bmp');
end;

{ TSpel }

function TSpel.CanMove(ACharacter: TFieldObject;
  ADirection: TDirection): Boolean;
begin
 Result := True;
 case ADirection of
  dUp     : Result := ACharacter.FPosition.Y > 0;
  dDown   : Result := ACharacter.FPosition.Y < FFieldCorner.Y div rectsize - 1;
  dLeft   : Result := ACharacter.FPosition.X > 0;
  dRight  : Result := ACharacter.FPosition.X < FFieldCorner.X div rectsize - 1;
 end;
end;

constructor TSpel.Create(const AWidth, AHeight: Integer; const ACanvas: TCanvas);
begin
  Create();
  FFieldCorner.X := AWidth;
  FFieldCorner.Y := AHeight;
  FCanvas := ACanvas;
end;

constructor TSpel.Create;
begin
  inherited Create;
  FCharacters := TObjectList.Create;
  FGadgets    := TObjectList.Create;
  FPacMan := TPacMan.Create;
  FTimer := TTimer.Create(nil);
  with FTimer do begin
    Interval := 1000 div loopInterval;
    OnTimer := Self.GameLoop;
    Enabled := True;
  end;
end;

destructor TSpel.Destroy;
begin
 FCharacters.Free;
 FGadgets.Free;
 FTimer.Free;
 FPacMan.Free;
 inherited;
end;

procedure TSpel.Draw();
var i: Integer;
begin
 FCanvas.FillRect(Rect(0, 0, FFieldCorner.X, FFieldCorner.Y));

for i := 0 to (FFieldCorner.X div rectsize) do begin
  FCanvas.MoveTo(i * rectsize, 0);
  FCanvas.LineTo(i * rectsize, FFieldCorner.Y);
 end;
 for i := 0 to (FFieldCorner.Y div rectsize) do begin
  FCanvas.MoveTo(0, i * rectsize);
  FCanvas.LineTo(FFieldCorner.X, i * rectsize);
 end;

 FPacMan.Draw(FCanvas);
 for i := 0 to FCharacters.Count - 1 do
  TFieldObject(FCharacters.Items[i]).Draw(FCanvas);
 for i := 0 to FGadgets.Count - 1 do
  TFieldObject(FGadgets.Items[i]).Draw(FCanvas);
end;

procedure TSpel.GameLoop(Sender: TObject);
var i : Integer;
    monster: TMovingObject;
    gadget : TGadget;
begin
 FTimer.Enabled := False;

 if (FCharacters.Count < 5) and (Random(10) > 8) then
  FCharacters.Add(TMonster.Create);

 if (FGadgets.Count < 20) then
  if (Random(100) > 90) then
    FGadgets.Add(TBurger.Create)
  else if (Random(100) < 10) then
    FGadgets.Add(TWater.Create); 

 Inc(FWholeSecond, 1000 div loopInterval);
 if (FWholeSecond >= 1000) then
 begin
  for i := 0 to FCharacters.Count - 1 do begin
   monster := TMovingObject(FCharacters.Items[i]);
   while (not CanMove(monster, monster.Direction)) or
      (Random(10) = 5) or (monster.Direction = dNone) do
     monster.Direction := TDirection(RandomRange(0, 16) mod 4);
   monster.Move;
   if monster.Intersects(FPacMan) then
     monster.PacmanIntersect(TFieldObject(FPacMan));
  end;
  FWholeSecond := 0;
 end;

1. Het monster kan niet verder in de richting waarin het ging
2. Het monster heeft gewoon zin om een andere kant op te gaan (oftewel: uit een Random getal tussen 0 en 10 komt toevallig 5).
3. Het monster staat stil.

for i := FGadgets.Count - 1 downto 0 do begin
  gadget := TGadget(FGadgets.Items[i]);
  if gadget.Intersects(PacMan) then begin
   gadget.PacmanIntersect(TFieldObject(FPacMan));
   FGadgets.Delete(i);
   Continue;
  end;
 end;

1. De PacManIntersect wordt opgeroepen. Deze doet nu nog niets, maar het is bijvoorbeeld denkbaar dat bepaalde objecten schadelijk zijn en Hitpoints afnemen, of dat de score van een bepaald object random bepaald wordt zodra Pacman het wil pakken (PacManIntersect mag immers FScore ook aanpassen en niet alleen de constructor).
2. De score variabele van TSpel wordt opgehoogd met de score van het geraakte object.
3. Het object wordt uit te lijst gewist.

 Draw;
 FTimer.Enabled := True;
end;

function TSpel.GetScore: Integer;
begin
  Result := FPacMan.Score;
end;

procedure TSpel.Move(ADirection: TDirection);
begin
 if not CanMove(FPacMan, ADirection) then Exit;
 FPacMan.FDirection := ADirection;
 FPacMan.Move;
 if PacMan.IsDead then begin
  // Game over!;
  FTimer.Enabled := False;
 end;

end;

procedure TPacManForm.GameTimerTimer(Sender: TObject);
begin
 edtHitpoints.Text := IntToStr(Spel.PacMan.Hitpoints);
 edtScore.Text     := IntToStr(Spel.Score);
 edtTijd.Text      := IntToStr(StrToInt(edtTijd.Text) - 1);
 if edtTijd.Text = '0' then begin
  ShowMessage('Uw tijd is op');
  GameTimer.Enabled := False;
  Spel.Free;
 end;


end;

Het einde...

Als je dat allemaal doorgelezen hebt: gefeliciteerd! Het kostte even tijd, maar je hebt er ook wat voor
Je kunt de broncode van het hele programma hieronder downloaden. Het programma is natuurlijk nog lang niet af. Lees de broncode nog eens door, en probeer wat verbeteringen / uitbreidingen aan te brengen. Er kunnen nog veel meer monsters in bijvoorbeeld. En misschien weet je andere toepassingen dan het spelletje tegen de klok wat ik nu gemaakt heb. Er zitten ook nog wat kleine foutjes in, zo gaan de monsters altijd naar de linkerrand (?).

Nog enkele opmerkingen...

• In alle klassen die zichzelf op het veld tekenen (dus TFieldObject en alle afgeleiden) is het nu zo dat de constructors ook het juiste plaatje laden. Waarschijnlijk zou het netter zijn om hiervoor een aparte method LoadImageFromFile te maken, die vanuit de constructor van TFieldObject wordt aangeroepen. Vervolgens hoeven de meeste klassen niet meer de constructor te overriden, maar alleen LoadImageFromFile.
• In een meer geavanceerd ontwerp zou in TSpel in plaats van twee TObjectLists een aparte TManager-klasse meer op zijn plaats zijn. Hiervan zouden dan TGadgetManager en TMonsterManager afgeleid worden die de objecten aanmaken, beheren, tekenen, vrijgeven, zoeken, sorteren, enzovoorts.
• De Score property van PacMan zou in plaats van direct naar FScore te schrijven een setter kunnen hebben, of Pacman zou een public method AddToScore kunnen krijgen.
• Nu loopt het spel niet zo soepel. De reden is dat na Pacman.Move niet wordt gecontroleerd op intersecties met monsters en gadgets. De code die dit doet staat al in GameLoop, deze zou naar een private method kunnen verhuizen die vervolgens vanuit zowel TSpel.GameLoop als TSpel.Move aangeroepen wordt.
• In dit artikel heb ik nog een hele hoop weggelaten. Ik heb het niet over interfaces gehad, en over published. Ik wilde dit artikel echter beperken tot de basisbegrippen (en toepassing daarvan) van OOP, en daarbij meteen de Delphi syntax laten zien.
• Een m.i. zeer goed boek om OO te leren denken is C++ in 24 uur van Jesse Liberty. Het is dan wel C++, maar in de loop van het boek worden onder andere de concepten die ik hier behandeld heb uitgebreider naar voren gebracht.