Originally Posted by
Slauerhoff
Nee ik vind OOP zeer interessant.
[...]
Hoe is zoiets ontstaan? Die omslag van procedureel naar OOP? Slimme denkers en/of de toegenomen snelheid van processoren?
Nee hoor, niets van dat alles.
Het is alleen op een andere manier aankijken tegen een probleem: het opdelen
van één groot probleem in kleine sub-probleempjes, waarbij ieder sub-probleem
z'n eigen "Object" is.
Je moet het ook niet te ingewikkeld zien: toen ik de overstap maakte van procedureel
naar object ge?Ârienteerd (met Turbo Vision onder DOS), begreep ik er eerste instantie
ook de ballen van
Onder "Ouderwets" Pascal schreef je iets als:
Pascal Code:
Program Iets;
Uses
Crt;
Var
Waarde : String;
Begin
ClrScr;
Repeat
WriteLn('Voer een tekst in...');
ReadLn(Waarde);
ClrScr;
WriteLn('Je tikte de tekst "' + Waarde + '" in!');
Until (Waarde = 'stop');
End.
Je begon bij het begin, liep de code door van boven naar beneden, totdat er aan een
bepaalde voorwaarde was voldaan en je stopte weer.
Onder een grafische omgeving, zoals bij Windows, is het eigenlijk heel onhandig
om te werken met een enkel scherm waar tekst van boven naar beneden geprint
wordt en waar je in datzelfde scherm ook in een bepaalde volgorde input van jou
verwacht wordt.
Het mooiste zou dus zijn wanneer je, afgaande op bovenstaande Pascal-code, de
beschikking zou hebben tot "Iets" wat een tekst kan weergeven en een ander "Iets"
waar een gebruiker weer tekst in kwijt kan.
Een derde "Iets" geeft de code de opdracht om dan iets te doen wanneer de gebruiker
dat pas wilt (de klant is tenslotte koning, niet de software).
Deze "Ietsen" noemen we dan "Objecten" en deze objecten zijn zelf verantwoordelijk
voor hetgeen ze geschreven zijn.
Het zouden dan bijvoorbeeld in dit geval een TLabel, TEdit en een TButton kunnen
zijn.
Een TLabel zorgt ervoor dat tekst weergegeven kan worden in een apart venstertje,
een TEdit geeft de gebruiker de mogelijkheid om tekst in te voeren en op een TButton
kan de gebruiker drukken wanneer hij dit wilt.
Je kunt dit dan vergelijken met een team: je hebt een manager ("De baas" - jij dus) die
alle zaken overziet en die tegen Pietje (TLabel) zegt: "Ga daar in het kantoor staan en
hou dit A4'tje vast met deze tekst".
Klaas (TEdit) moet als luisterend oor dienen voor inkomende teksten en Jan (TButton)
moet de manager een gil geven wanneer er iemand bij hem aanbelt.
Als manager hoef je je dus helemaal geen zorgen meer te maken over de werking
van deze "Werknemers": zolang je ze goed aanstuurt (positie op een formulier, de kleur,
afmetingen, ...), kun je ze gewoon aansturen door eerst hun naam te roepen, daar een
punt achter te zetten, gevolgd door hetgeen je wilt instellen of uitlezen.
Delphi Code:
Procedure TTestForm.FormCreate(Sender: TObject);
Begin
Label1.Caption := 'Voer een tekst in...';
Edit1.Text := '';
End;
Procedure TTestForm.Button1Click(Sender: TObject);
Begin
If (Edit1.Text = 'stop') Then
Close
Else
Label1.Caption := Edit1.Text;
End;
Eigenlijk verschilt object ge?Ârienteerd niet zo heel veel van procedureel programmeren;
code wordt nog steeds van "Begin" tot "End." uitgevoerd, alleen het verloop van de code
is van te voren niet voorspelbaar en is geheel afhankelijk van de input van de gebruiker
(alles is "Event-driven").
Het grote voordeel van OOP is dat jij, als programmeur (of manager), niet alles zelf
hoeft bij te houden, maar dat alle objecten dit voor je doen.
Slechts (of pas) als jij dat wilt, kun je dingen instellen, opvragen en uit laten voeren
zonder dat je je er zorgen over hoeft te maken of het wel goed gebeurt.
Greetz,
Peter.
Bookmarks