Tom van Overloop (S135594) Januari 2010, Communication & Multimedia Design, Avans Hogeschool, Breda
O O P
I NP H P
H
E T O N D E R G E S C H O V E N K I N D D A T V O L W A S S E N W E R DW
O O R D V O O R A FIk wil graag Renée Kool en Harold Konickx bedanken voor hun begeleiding tijdens het tot stand komen van deze scriptie. Dankzij de input en feedback die ik van hen kreeg is dit onderzoeksverslag geworden tot was het is. Daarnaast wil ik ook Joep Rongen bedanken voor het controleren van deze scriptie. Joep is een vriend van mij die al enkele jaren actief is als programmeur, hij heeft voor mij gecontroleerd of de tekst inhoudelijk en technisch klopt. Bedankt, Tom van Overloop
I
N H O U D S O P G A V ET i t e l P a g i n a 1. Inleiding 1 2. Definitie 5 Definitie 6 Classes en Objects 6 Syntax 8 Toepassing 11 Samenvatting 12 3. Mogelijkheden 13 Overerving 13 Interfaces 16 Integriteit 18 Onderhoudbaarheid 20 Schaalbaarheid 22 Samenvatting 23 4. Valkuilen 25 Praktische redenen 25 Persoonlijke voorkeur 26 Technische redenen 27 Samenvatting 28 5. Conclusie 29 6. Notenapparaat 30 7. Bibliografie 31
1 | P a g i n a
1 .
I
N L E I D I N G De manier waarop een webpagina wordt gemaakt is veel veranderd in de afgelopen decennia. De basis van het vak webontwikkelaar, iemand die applicaties maakt voor het web, werd begin jaren 90 gelegd. In die periode bedacht Tim Berners‐Lee de HTML standaard. Zijn gedachtegoed had al snel de komst van de eerste webbrowsers tot gevolg, waarmee het wereldwijde web in een stroomversnelling kwam. Het web won aan populariteit bij zowel de zakelijke als de particuliere gebruikers ervan. Echter al snel bleek dat het gebruik van enkel HTML een beperking was waardoor webontwikkelaars zich niet tegen lieten houden. Dit resulteerde in de ontwikkeling van vele nieuwe technieken die de mogelijkheden van een webapplicatie uitbreidt. Deze ontwikkelingen hebben ervoor gezorgd dat een webontwikkelaar in het jaar 2010, bij het maken van een webapplicatie, vele technieken met elkaar combineert. Enkele voorbeelden van de front‐end technieken die webontwikkelaars anno 2010 naast HTML tot hun beschikking hebben zijn CSS, Javascript en Flash. Bij ieder project moet beslist worden welke front‐end technieken ingezet gaan worden om het gewenste resultaat te behalen. Deze beslissing kan echter niet alleen gemaakt worden op basis van persoonlijke voorkeur of technische mogelijkheden. De ontwikkelaar moet namelijk ook rekening houden met het feit dat eindgebruikers verschillende besturingssystemen en browsers gebruiken. Hierdoor moeten ontwikkelaars zich vaak in vele bochten wringen om alle eindgebruikers hetzelfde resultaat te tonen. Naast alle front‐end uitdagingen van tegenwoordig heeft de ontwikkelaar ook aan de back‐end kant beslissingen te maken. Wanneer er bij een project gekozen wordt om een webapplicatie dynamisch te maken, zal onder andere een keuze gemaakt moeten worden voor een scripttaal, een server, een databasetype en een systeem waarop dit gaat draaien. Het aanbod van verschillende technieken is enorm en allen hebben hun eigen voor –en nadelen. Deze scriptie richt zich alleen op de ontwikkelaars die als scripttaal kiezen voor PHP (PHP Hypertext PreProcessor). Deze techniek heeft de laatste jaren echter een ontwikkeling ondergaan die de ontwikkelaar dwingt nóg een keuze te maken. Deontwikkelaar zal een beslissing moeten nemen over het wel of niet gebruik maken van object georiënteerd programmeren (vaak afgekort als OOP – Object Oriented Programming). PHP is veruit de meest gebruikte scripttaal voor webapplicaties op dit moment. Dat komt doordat het pakket gratis, de techniek bewezen en de taal eenvoudig aan te leren is. PHP is een Open Source pakket, wat betekent dat het gebruik ervan gratis is en het inrichten van een server goedkoop. Dit is voor veel studenten, maar ook bedrijven, een goede reden om te kiezen voor deze taal. PHP heeft zichzelf bewezen op het gebied van dynamische webapplicaties. De taal bestaat immers al bijna 15 jaar en wordt al die tijd al tot tevredenheid van velen gebruikt. Doordat zoveel webontwikkelaars gebruik maken van PHP is de infrastructuur zeer volwassen en heeft het een grote, actieve community achter zich. Daar komt ten slotte nog bij dat het aanleren van de taal relatief eenvoudig is in vergelijking met talen als C++, JAVA en ASP. Dit heeft tot gevolg dat veel beginnende ontwikkelaars de keuze maken voor PHP, waardoor het voortbestaan van deze techniek gewaarborgd wordt. PHP had echter nooit zo groot kunnen worden als de ontwikkeling ervan niet continu was doorgegaan. De eerste versie van PHP Tools, toen nog afkorting van Personal Home Page Tools, die in 1995 op de markt kwam vertoont vrijwel geen overeenkomsten meer met de meest recente uitgave PHP 5.3.1. In de relatief korte periode dat PHP bestaat zijn er onnoemelijk veel mogelijkheden toegevoegd aan het pakket. Een onderdeel dat sinds PHP 3.0 in 1998 is toegevoegd aan PHP is de Zend Engine1. Deze toevoeging maakte het mogelijk om in PHP object georiënteerd te programmeren. In die tijd waren veel webontwikkelaars enthousiast over OOP, maar er was ook veel kritiek op de makers van PHP. Doordat OOP pas op het laatst toegevoegd werd aan PHP 3, was het in die tijd een ondergeschoven kindje. De kritiek op deze opzet verstomde toen met de introductie van PHP 5 ook de nieuwe Zend Engine 2 beschikbaar werd. Met de komst van deze nieuwe Engine was OOP in PHP niet meer een ondergeschoven kind, maar een volwassen OOP taal. Velen hebben sindsdien de object georiënteerde aanpak omarmd en gebruiken deze bij de ontwikkeling van hun webapplicaties.
3 | P a g i n a Deze scriptie is gericht op de studenten van de opleiding van Communcatie & Multimediadesign en dan specifiek op diegenen die de afstudeerrichting Creative Technology hebben gekozen. Ik ga er vanuit dat de lezer van deze scriptie ervaring heeft met procedureel programmeren en interesse heeft in het gebruik van OOP. De student waarvoor deze scriptie geschreven is zal, net als iedere ontwikkelaar, op een bepaald moment in zijn carrière te maken krijgen met OOP. Is het niet tijdens zijn opleiding of training, dan wel in de beroepspraktijk. De overstap van procedureel programmeren naar object georiënteerd programmeren is geen makkelijke. De vraag die veel, in OOP geïnteresseerde, ontwikkelaars zichzelf stellen heeft centraal gestaan in het onderzoek en luidt als volgt: Wat heeft OOP mij te bieden? Om een goed onderbouwd antwoord te kunnen geven op deze vraag heb ik de volgende hoofdstukindeling gemaakt waarin ik uitleg geef over het gebruik van OOP in PHP. Definitie. In dit hoofdstuk geef ik uitleg over het ontstaan van OOP, waarna ik een definitie opstel die ontstaan is uit mijn onderzoek. Vervolgens wordt uitleg gegeven over die definitie aan de hand van voorbeelden waarin ik ook de syntax van OOP laat zien. Ten slotte confronteer ik de lezer met het feit dat hij ooit, bewust of onbewust, in aanraking zal komen met object georiënteerd programmeren. Mogelijkheden. In dit hoofdstuk ga ik dieper in op definitie. Ik geef daarbij uitleg over de voordelen van het gebruik van OOP en waar die voordelen uit voortkomen. Ik ga dieper in op de mogelijkheden van object georiënteerd programmeren die kenmerkend zijn voor de aanpak en de termen die daarbij horen. Valkuilen. In dit hoofdstuk geef ik uitleg over wat beweegredenen kunnen zijn van een ontwikkelaar om wel, of niet, te kiezen voor het gebruik van OOP. Ik vind het belangrijk om stil te staan bij de aspecten die deze keuze kunnen beïnvloeden om zo de lezer bewust te maken van de valkuilen die er zijn.
Nadat de lezer al deze informatie weet, geef ik hem in de conclusie mijn mening over het gebruik van OOP in PHP.
5 | P a g i n a
2 .
D
E F I N I T I EObject‐oriented programming, of te wel object georiënteerd programmeren is een begrip dat menig ontwikkelaar intimideert. Het draagt een bepaalde mystiek met zich mee, maar waar komt die mystiek vandaan? Erkend PHP‐expert David Powers stelt in zijn boek Object Oriented Solutions dat ‘Part of the mystique stems from the fact that OOP was originally the preserve of graduates in computer science—a mystique deepened by concepts with obscure sounding names, such as encapsulation, polymorphism, and loose coupling2. Vrij vertaald stelt Powers dat deze mystiek komt doordat OOP van oorsprong alleen werd gebruikt door computerwetenschappers. Die mystiek wordt volgens Powers aangedikt door het gebruik van obscuur klinkende termen als encapsulation, polymorphism en loose coupling. Procedurele ontwikkelaars schrikken vaak van de moeilijke termen die OOP ontwikkelaars gebruiken om met elkaar te communiceren. Deze onbekende woorden boezemen veel OOP‐leken angst in. Om het nut van OOP goed te kunnen begrijpen is het noodzakelijk om de herkomst ervan te kennen. OOP is ontstaan rond 19673. Ontwikkelaars kwamen er in die periode achter dat het, met de steeds groeiende applicaties, moeilijker werd om hun programmatuur te onderhouden. De programma’s die zij schreven zonden instructies naar een computer die ze sequentieel uitvoerde, ongeveer op dezelfde manier als veel PHP applicaties dat nu doen. Het stapsgewijs schrijven van code voor deze programma’s – beter bekend als procedureel programmeren – werkte prima voor korte stukken code en simpele applicaties. Naarmate de programma’s groter en ingewikkelder werden en het aantal regels code dat deze telden toenam, werd het echter lastiger om fouten terug te vinden. Het werd steeds moeilijker om de code te onderhouden4. De oplossing voor dit probleem werd gevonden in het verdelen van de lange, procedurele code in logische onderdelen. Bij deze opdeling verdwijnt alle functionaliteit uit het script en wordt deze gebundeld wordt in speciale delen, genaamd classes. In die verschillende classes zit de functionaliteit – het verwerken van
de data – van de applicatie. Door het gebruik van deze manier van programmeren wordt het script een lijst van instructies aan de desbetreffende classes. In deze scriptie worden de begrippen script en code veelvuldig door elkaar gebruikt, maar deze woorden betekenen niet hetzelfde. Bij procedureel programmeren staat de programmatuur chronologisch onder elkaar. Eerst wordt een bepaald stuk code uitgevoerd, daarna het volgende stuk. Deze code wordt ook wel script genoemd. Bij procedureel programmeren wordt er in deze scriptie geen onderscheid gemaakt tussen de twee termen. Bij OOP gebeurt dat wel. Wanneer het bij OOP gaat over code, dan wordt gerefereerd naar een class of classes en wanneer het over het script gaat dan wordt de programmatuur bedoeld die opdrachten geeft aan de classes. Het script geeft dus opdrachten aan de code. DE F I N I T I E Tijdens het onderzoek voor deze scriptie heb ik niet één duidelijk definitie voor OOP gevonden, dat bleek echter geen probleem. Tijdens het schrijven kwam ik vanzelf tot een basisgedachte over OOP in PHP. De gedachte achter OOP en de mogelijkheden die het biedt zijn allemaal, direct of indirect te herleiden naar de volgende definitie: Object Georieneerd Programmeren: Manier van programmeren waarbij de code opgedeeld wordt in logische onderdelen. Deze opdeling wordt gedaan ter bevordering van de onderhoudbaarheid, schaalbaarheid en integriteit van een applicatie. CL A S S E S E N OB J E C T S Zoals de definitie aangeeft is de belangrijkste eigenschap van object georiënteerd programmeren het opdelen van code in logische onderdelen. Deze opdeling wordt gedaan in classes, welke vanuit het script kunnen worden gebruikt door objects. De begrippen class en object worden regelmatig door elkaar gebruikt, dit komt vaak doordat gebruikers het verschil tussen de twee niet goed begrijpen. Sommige gebruikers beweren dat een class een definitie van een object is en andersom. Deze beweringen zijn verwarrend voor veel ontwikkelaars die zich verdiepen in de object georiënteerde aanpak van programmeren. Het verschil tussen een class en een object is in het begin moeilijk, maar essentieel om de werking en het nut van OOP te kunnen
be vo In va w ee w al ob m Fi De pr ee va ee egrijpen5. H oorbeeld uit n een fabrie an de produ worden met en object. D waarmee ze lemaal unie bjects uit te meerdere ob guur 1. Gra e eigenscha roperty (eig en variabele ariabele, ka en string (te Het verschil t de fysieke k waar spee uctielijn. De een class. H De vorm die geperst wo eke objecte e genereren bjects kunne fische weer appen die e genschap) is e in een clas n een prope ekst), een b tussen beid e wereld. elgoedsolda mal waar d Het poppetj e de soldate orden (class) n (object). E n. In Figuur 1 en ontstaan rgave van d en class gee s niets ande ss gebruikt, erty versch oolean (tru de is duideli aatjes word deze soldate je dat uit de n hebben s ). Alle solda Een class is 1 wordt gra n met allem de verhoudi eft aan een ers dan een , wordt deze illende waa e of false) o ijk te maken en gemaak en mee gem e mal komt taat vast en aten zien er dus een tem afisch weerg aal dezelfde ng tussen c object wor variabele. W e een prope ardes bevatt of een array n aan de ha t rollen jaar maakt word kan vergele n wordt bep hetzelfde u mplate die gegeven dat e eigenscha lasses en ob rden proper Wanneer ee erty genoem ten zoals ee y. Een prope 7 | P a nd van een rlijks vele so den kan verg eken worde paald door d uit, maar he gebruikt wo t uit een cla appen. bjects.6 rties genoem en ontwikke md. Evenals en integer (g erty wordt o a g i n a oldaten geleken en met de mal et zijn ordt om ass md. Een elaar s een getal), op
dezelfde manier aangemaakt als een variabele, namelijk met het $‐teken. In het voorbeeld van de speelgoedsoldaten zou de lengte een property zijn. Naast properties kan een class ook verschillende methods bevatten. In het voorbeeld van de speelgoedsoldaatjes was dit niet het geval, maar in het voorbeeld op de volgende pagina zal dit duidelijk gemaakt worden. Een method (methode) is een andere benaming voor een functie in een class. Een method wordt ook hetzelfde als een functie aangemaakt, namelijk door het woord function, gevolgd door de functienaam met daarachter variabelen die je mee wilt geven aan de functie tussen haakjes. De methods zorgen voor de functionaliteit – data verwerking – van de class. DE S Y N T A X De syntax van OOP in PHP is te uitgebreid om volledig te behandelen in deze scriptie. Toch wordt hieronder een eenvoudig voorbeeld gegeven van een class en een object. In dit voorbeeld wordt slechts een zeer klein deel van de mogelijkheden van OOP benut. Om een goed beeld te krijgen van de mogelijkheden van object georiënteerd programmeren is het belangrijk om te weten hoe de code eruit ziet. In het volgende voorbeeld wordt wederom een weerspiegeling van de fysieke wereld nagebootst. De class Beer is de template voor berenobjects. Net als de
speelgoedsoldaten hebben ook beren bepaalde eigenschappen. Beren hebben een leeftijd, een naam en een bepaald gewicht. Maar in tegenstelling tot
speelgoedsoldaatjes hebben beren ook functionaliteiten. De beren in dit voorbeeld kunnen eten. Hieronder staat de class met de genoemde eigenschappen en
9 | P a g i n a
// Deze class is opgeslagen in het bestand class_Beer.php class Beer
{
public $leeftijd; public $naam; public $gewicht;
public function __construct($naam, $gewicht) {
$this->leeftijd = 0;
$this->naam = $naam;
$this->gewicht = $gewicht; }
public function eet($maaltijd) { if ($maaltijd == 'fruit') { $this->gewicht += 100; } if ($maaltijd == 'honing') { $this->gewicht += 200; } }
public function toonNaamGewicht() {
echo 'Beer '.$this->naam.' weegt '.$this->gewicht. ' gram.'; } } De class wordt aangemaakt en krijgt de naam Beer. Als eerste worden alle properties aangemaakt die gebruikt gaan worden. Vervolgens wordt de eerste method, de constructor aangemaakt. De constructor wordt aangeroepen als een object wordt aangemaakt. Een beer heeft bij geboorte al bepaalde basiseigenschappen, dat geldt ook voor een object. Deze basiseigenschappen worden aan een object gegeven bij het ontstaan ervan. In dit voorbeeld heeft een object bij het aanmaken al een naam en een bepaald gewicht die opgegeven worden bij het aanmaken van het object. Met $this-> gevolgd door een property‐naam wordt binnen OOP een property aangeroepen. Op deze manier kan de waarde van een property uitgelezen of aangepast worden. In dit voorbeeld wordt de leeftijd van een object bij het aanmaken op 0 gezet, net als in het
echt zijn beren 0 bij geboorte. Daarnaast worden de naam en het gewicht opgeslagen in het object. Daarna volgen overige methods. Deze class heeft een method eet(), waarin het eetgedrag van een beer beschreven staat. Zoals uit de code is op te maken komt een beer 100 aan wanneer hij fruit eet en 200 als hij honing eet. De methode toonNaamGewicht() doet precies wat de naam al aangeeft, hij toont bij het aanroepen de naam en het gewicht van het object. In dit voorbeeld staat voor elke property of method het woord public. Deze declaratie heeft te maken met een belangrijk aspect van OOP genaamd inkapseling, meer uitleg hierover volgt in het volgende hoofdstuk. Nu de code van de class Beer is geschreven, volgt een voorbeeld van hoe een berenobject gemaakt wordt in het script.
// Dit script is opgeslagen in het bestand beer.php require_once 'class_Beer.php';
$beer1 = new Beer('Ruud', 700); $beer1->eet('honing');
$beer1->toonNaamGewicht();
In dit voorbeeld wordt class_Beer.php geladen in het script zodat deze beschikbaar is voor gebruik. Vervolgens wordt er een nieuw (new) object aangemaakt, wat een instantie is van de class Beer. Dit object krijgt de naam Ruud en een gewicht van 700, welke door de __construct() method opgeslagen worden in het object. Nadat het object is aangemaakt gaat Ruud honing eten, dit doet hij met behulp van de methode eet(). Daarna wordt de methode toonNaamGewicht() aangeroepen. De uitvoer van deze methode is de volgende zin: "Beer Ruud weegt 900 gram”. De 900 gram die beer Ruud weegt is een optelsom van zijn gewicht bij zijn geboorte, namelijk 700 en de honing die hij gegeten heeft, welke 200 aan zijn gewicht heeft toegevoegd. Zoals al eerder aangegeven werd is dit een vereenvoudigd voorbeeld van hoe een objectgeoriënteerde applicatie er uit zou kunnen zien. Buiten dat het een inzicht geeft in de syntax die hoort bij OOP, wordt hier in praktijk weergegeven wat eerder al in theorie beschreven is over classes en objects. Ook de scheiding tussen de code en het script wordt door bovenstaand voorbeeld nog eens duidelijk benadrukt.
11 | P a g i n a TO E P A S S I N G Een slimme ontwikkelaar maakt gebruik van de code die reeds geschreven is. Er is met PHP al zo veel gemaakt, dat een slimme webontwikkelaar daar gebruik van maakt. Waarom zou hij het wiel opnieuw uitvinden? Gelukkig is het algemeen geaccepteerd onder webontwikkelaars om code van elkaar te gebruiken. Het is zelfs zo dat veel ontwikkelaars hun code online aanbieden, opdat anderen hier gebruik van kunnen maken. Wanneer een ontwikkelaar op zoek gaat naar een stuk code die hij kan gebruiken voor zijn webapplicatie, kan hij uitkomen bij een object georiënteerd stuk code dat precies doet wat hij nodig heeft. Een andere situatie waarin een ontwikkelaar in aanraking kan komen met OOP is tijdens het werken in teamverband. Wanneer de ontwikkelaar bijvoorbeeld vanuit een CMS (content management sytem) van een collega moet werken dat volledig object georiënteerd is. Een ander scenario waarin een ontwikkelaar in aanraking kan komen met OOP is bij het gebruiken van een framework. Een framework zorgt ervoor dat simpele, veel voorkomende taken, niet door de ontwikkelaar gedaan hoeven te worden. Sinds versie 4 van PHP zijn frameworks heel veel mogelijkheden van OOP gaan gebruiken. Door deze ontwikkeling zijn veel ontwikkelaars OOP moeten gaan denken om gebruik te kunnen maken van hun favoriete framework. Het is dan ook te verwachten dat een ontwikkelaar die in aanraking komt met een PHP framework, ook het object georiënteerd programmeren aan zal moeten leren. Naast situaties waar in ontwikkelaar gebruik kan maken van OOP, zijn er ook situaties waarin hij dit moet. Een voorbeeld hiervan is bij het opzetten van een SOAP verbinding. De SOAPClient is vanaf PHP5 namelijk helemaal object georiënteerd en laat de ontwikkelaar dus geen keus. Zo zijn er binnen PHP meer voorbeelden te noemen en het is aannemelijk dat er in de toekomst meer toepassingen enkel object georiënteerd gedaan kunnen worden, daar moet de ontwikkelaar zich van bewust zijn. Om een goed beeld te krijgen van wat OOP is, moet niet alleen gekeken worden naar de gedachte erachter of welke functionaliteiten het biedt, maar ook naar de toepassing ervan. Die toepassingen zijn in toenemende mate te vinden, aangezien OOP
in PHP steeds meer gebruikt wordt. De meeste ontwikkelaars van webapplicaties zullen tijdens hun carrière ooit, bedoeld of onbedoeld, in aanraking komen met OOP. SA M E N V A T T I N G In dit hoofdstuk leg ik aan de lezer uit wat OOP inhoudt. Om dat goed te kunnen begrijpen vertel ik dat deze manier van programmeren ontwikkeld is doordat steeds groeiende procedurele applicaties niet goed te onderhouden waren. De oplossing hiervoor werd gevonden in het opdelen van de procedurele code in logische delen genaamd classes. In deze classes zit de functionaliteit – het verwerken van data – van de applicatie. Een class bevat properties, vergelijkbaar met variabelen en methods, vergelijkbaar met functies. Een class is een mal voor het maken van meerdere objects, deze objects kunnen gebruik maken van de properties en methods die in de class staan. Om de opzet van classes en objects duidelijk te maken en om inzicht te verschaffen in de syntax die hoort bij OOP, geeft ik vervolgens een voorbeeld van hoe deze eruit zien. Tot slot leg ik aan de hand van enkele voorbeelden uit waarom een ontwikkelaar rekening moet houden met OOP. Deze aanpak voor het ontwikkelen van webapplicaties wordt in toenemende mate gebruikt en de lezer moet zich ervan bewust zijn dat hij op enig moment hiermee te maken gaat krijgen. Het opdelen van de code in logische delen zorgt ervoor dat een applicatie beter te onderhouden is, maar waar komt dat dan door? Naast het verbeteren van de onderhoudbaarheid zorgt het gebruik van OOP er ook voor dat een applicatie beter schaalbaar en de integriteit hoger wordt, waar kom dat door? Antwoorden op deze vragen worden in het volgende hoofdstuk gegeven.
13 | P a g i n a
3 .
M
O G E L I J K H E D E NIn het vorige hoofdstuk was te lezen dat het gebruik van OOP een webapplicatie beter onderhoudbaar en schaalbaar maakt en dat de integriteit ermee vergroot wordt. In dit hoofdstuk leg ik uit door welke toepassingen deze voordelen benut kunnen worden en waarom. Ik zal hierbij dieper ingaan op de mogelijkheden die kenmerkend zijn voor OOP en de termen die daarbij horen. Allereerst wil ik terug komen op het gebruik van classes bij OOP. Deze opzet biedt de ontwikkelaar meer dan alleen het logisch opdelen van code. De belangrijkste mogelijkheden die het gebruik van classes een object georiënteerde ontwikkelaar biedt zijn overerving en interfaces. OV E R E R V I N G Overerving (in het engels inheritance) staat voor de mogelijkheid om een class de properties en methods van een andere class te laten erven, zoals uit het begrip is op te maken. In de wereld waarin wij leven erft ieder kind de genen van zijn ouders. Deze genen bevatten uiterlijke en innerlijke eigenschappen van de ouders, evenals hun gedrag. Bij classes gebeurt dit ook. Ieder kind (child class of subclass) erft de eigenschappen en het gedrag van zijn ouder (parent class of superclass). Dit houdt in dat een child class de properties en methods van de parent class overerft7. Het concept achter overerving is duidelijk te maken aan de hand van het voorbeeld van de beer uit het vorige hoofdstuk. In dat voorbeeld wordt uitgelegd hoe een simpele class in elkaar zit. Uit deze class kunnen een heleboel beerobjecten gemaakt worden, maar deze zullen allemaal op elkaar lijken. Dat is niet zoals het in de natuur gaat. In de fysieke wereld heeft iedere beer de eigenschappen van de class Beer, maar elke soort heeft eigen karakteristieken. Omdat alle beren de eigenschappen uit de Beer class hebben kan deze als parent class worden gebruikt. Die eigenschappen worden overgeërfd door de child classes als BruineBeer, Grizzlybeer en Ijsbeer.
Wanneer gebruikt wordt gemaakt van overerving, krijgen deze child classes alle
properties en methods mee van de parent class. Vervolgens kunnen deze aangevuld of overschreven worden door eigen karakteristieke properties en methods. Regel bij het gebruik van overerving is dat een child altijd een parent is en niet andersom. Dit zou in PHP geschreven worden als:
Ch Pa De Fi He ge pa hild == Parent arent != Child e hiërarchie guur 2. Gra et aangeven ebruiken bij arent class B t // een ij // niet e e van overe fische weer n van een p j het maken Beer, ziet de sbeer is altijd elke beer is ee rving is graf rgave van d parent word n van de chi eze er als vo d een beer en ijsbeer fisch geïllus de overervin dt in php ge ild class. Wa olgt uit: streerd in fig ng. daan door h anneer Ijsbe guur 2. het woord e eer de child extends te class is, met als
15 | P a g i n a
// Deze class is opgeslagen in het bestand class_Ijsbeer.php class Ijsbeer extends Beer
{
public $kleur; public $soort;
public function __construct($naam, $gewicht) {
parent::__construct($naam, $gewicht); $this->soort = ijsbeer;
$this->kleur = wit; }
public function eet($maaltijd) { if ($maaltijd == 'zeehond') { $this->gewicht += 500; } if ($maaltijd == 'ringelrob') { $this->gewicht += 350; } }
public function zwem() {
// methode ter verduidelijking van overerving // deze methode bevat geen functionaliteiten }
}
Een object dat gebruik maakt van de Ijsbeer class wordt als volgt aangemaakt:
$ijsbeer1 = new Ijsbeer('Lisa', 500);
Dit heeft als resultaat dat het object $ijsbeer1 nu Lisa heet, ze weegt 500, heeft een leeftijd van 0, ze is wit en van de soort ijsbeer. Ze kan zeehond en walrus eten, ijsberen zijn echte carnivoren. Ook heeft Lisa een nieuwe functionaliteit genaamd zwem(). Ten slotte kan ze gebruik maken van de method toonNaamGewicht() wat als uitvoer de volgende zin zal tonen: “Beer Lisa weegt 500 gram.”.
Een child class kan de properties en methods van de parent class uitbreiden zoals in dit voorbeeld met de properties kleur en soort en de methode zwem() gedaan wordt. Een
child class kan ook een property of method van de parent class overschrijven. In dit voorbeeld wordt de methods eet() en __construct() uit de Beer class overschreven. Een ijsbeer heeft namelijk geen beschikking tot fruit en honing, maar eet in plaats daarvan zeehonden en ringelrobben. Een ijsbeer is namelijk een echte carnivoor. De makers van PHP hebben gekozen voor single inheritance, wat betekent dat een child class maximaal één parent class kan hebben8. Dit komt het overzicht en de eenvoud ten goede, maar is ook beperkend. Een ijsbeer is een beer, maar in tegenstelling tot alle andere beersoorten de enige pure carnivoor. Het zou daarom handig kunnen zijn om eigenschappen en functionaliteiten van zowel de class beer() als de class carnivoor() over te kunnen erven. Deze vorm van overerving is niet mogelijk in PHP. Toch zou ijsbeer Lisa de mogelijkheden van bovengenoemde classes willen benutten. IN T E R F A C E S Om Lisa gebruik te laten maken van zowel de class beer, als de class carnivoor, biedt PHP de implementatie van interfaces. Zoals een class een template is voor een object, kan een interface een template voor een class genoemd worden. In een interface staan geen properties, wel methods, deze methods hebben echter geen functionaliteit. Een interface is een lijst van methods die in de child class hun functionaliteit krijgen. Om duidelijk te maken hoe een interface eruit zou kunnen zien volgt hieronder een voorbeeld van een interface voor carnivoren. interface Carnivoor {
public function vang (); public function dood(); } Alle carnivoren vangen een prooi en doden het daarna, of in sommige gevallen gelijktijdig. Hoe zij dit doen kan voor iedere carnivoor anders zijn. Slangen kunnen hun prooi bijvoorbeeld doden door deze te vergiftigen of te laten stikken. Ijsberen hebben ook hun eigen methoden om hun prooi te vangen en te doden, dit verschilt per slachtoffer. Om te laten zien hoe een interface geïmplementeerd wordt is hieronder de class Ijsbeer opnieuw opgemaakt, maar dan met de parent Beer en de interface Carnivoor.
17 | P a g i n a
// Deze class is opgeslagen in het bestand class_Ijsbeer.php class Ijsbeer extends Beer implements Carnivoor
{
public $kleur; public $soort;
public function __construct($naam, $gewicht) {
parent::__construct($naam, $gewicht); $this->soort = ijsbeer;
$this->kleur = wit; }
public function eet($maaltijd) { if ($maaltijd == 'zeehond') { $this->gewicht += 500; } if ($maaltijd == 'ringelrob') { $this->gewicht += 350; } }
public function zwem() {
// methode ter verduidelijking van overerving // deze methode bevat geen functionaliteiten }
public function vang($prooi) {
if ($prooi == 'zeehond') {
// wacht boven ademgat tot zeehond boven komt }
if ($prooi == 'ringelrob') {
// speur naar hol met jongen en ga deze binnen }
}
public function dood($prooi) {
if ($prooi == 'zeehond') {
// geef klap op de kop } if ($prooi == 'ringelrob') { // dood bijten } } }
Een interface wordt geïmplementeerd door het woord implements te gebruiken. Bij de implementatie is het verplicht om iedere method die in de interface staat in de child class te definiëren. Wanneer dit niet gedaan wordt zal de applicatie een foutmelding weergeven. Net als voor overerving gelden er ook regels voor het gebruik van interfaces. Een van deze regels is dat, in tegenstelling tot het gebruik van overerving, een class meerdere interfaces kan hebben. Een ontwikkelaar kan zoveel interfaces als hij wil aan een class koppelen. De regels over hiërarchische verhoudingen zien er als volgt uit:
Child == Parent // een ijsbeer is altijd een beer Child == Interface // een ijsbeer is altijd een carnivoor Parent != Child // niet elke beer is een ijsbeer Parent != Interface // niet elke beer is een carnivoor Interface != Child // niet elke carnivoor is een ijsbeer Interface != Parent // niet elke carnivoor is een beer
Het grote voordeel van overerving en interfaces is te herleiden naar 2 doelen die onlosmakelijk met elkaar zijn verbonden. Enerzijds is het bevorderlijk voor de schaalbaarheid, anderzijds draagt het bij aan de onderhoudbaarheid van de webapplicatie. Verderop in dit hoofdstuk volgt meer uitleg over beide doelen. IN T E G R I T E I T Wanneer gesproken wordt over de integriteit van een applicatie gaat het over de betrouwbaarheid ervan. Het gebruik van OOP kan de betrouwbaarheid van een applicatie aanzienlijk verhogen. Een oplossing die object georiënteerd programmeren biedt ter vergroting van de integriteit is inkapseling. Door het gebruik hiervan zijn de data en functionaliteiten van een applicatie alleen te gebruiken op de plaats waar deze nodig zijn. Dit draagt bij aan de veiligheid en daarmee ook aan de betrouwbaarheid van de applicatie. Een andere mogelijkheid die OOP biedt om de integriteit van een applicatie te verhogen is de manier van foutafhandeling. Door fouten die optreden in de applicatie af te vangen kunnen deze snel achterhaald en aangepakt worden, hetgeen bijdraagt aan de betrouwbaarheid. Inkapseling (encapsulation in het engels) is een term die gebruikt wordt voor de beveiliging van data bij het gebruik van OOP. Het komt erop neer dat de data op de
19 | P a g i n a plaats opgeslagen wordt waar deze nodig is en deze, indien gewenst, niet vanaf een andere plaats in de code te benaderen is. Aan alle properties en methods in een class zijn declaraties (in het engels modifier) mee te geven. Deze declaraties staan voor verschillende gradaties van beveiliging. De mogelijke declaraties zijn public, private en protected. In de tabel hieronder is een overzicht te zien van wat het gebruik van de verschillende declaraties voor gevolgen heeft voor de beschikbaarheid van de property of method waaraan deze is toegewezen. Declaratie Betekent public Het gebruiken van deze declaratie heeft als gevolg dat de gebruiker volledige toegang heeft tot de property of method waaraan deze meegegeven is. De property of method kan in de class gebruikt worden waarin deze staat, in iedere child class en vanuit het script. protected Een protected method of property is te gebruiken binnen de class waarin deze staat en in iedere child class. private een protected property of method is alleen vanuit de class te benaderen waarin deze staat. Tabel 1. Een overzicht van declaraties van inkapseling en wat het gebruik ervan voor gevolgen heeft.
In de voorbeeldclasses Beer en Ijsbeer zijn alle properties en methods gedeclareerd met public, wat betekent dat deze vanuit de hele applicatie benaderbaar zijn. Public is de standaard declaratie, wat inhoudt dat een niet gedeclareerde property of method door PHP automatisch als public wordt beschouwd. Het is echter goed gebruik (good practice in het engels) om altijd een declaratie op te geven9. Hoewel het gebruik van inkapseling voordelen met zich mee brengt, creëert het ook bepaalde verantwoordelijkheden voor de ontwikkelaar. Het is zijn verantwoordelijkheid de juiste declaraties te gebruiken. Een property of een method die niet buiten de class gebruikt wordt, moet ook als zodanig worden gedeclareerd. Als inkapseling juist wordt toegepast is dit bevorderend voor de veiligheid en betrouwbaarheid van de applicatie. Ook wordt hierdoor de leesbaarheid voor een andere ontwikkelaar die de code ziet vergroot. Een andere ontwikkelaar snapt meteen wat een variabele mag en niet mag.
Een ander onderdeel van OOP dat bijdraagt aan de integriteit van de applicatie is de afhandeling van fouten. Hoe goed een webapplicatie ook is geschreven, tijdens het ontwikkelen en na oplevering zullen er problemen ontstaan. De problemen tijdens de ontwikkeling zijn volledig in handen van de ontwikkelaar. De fouten na de oplevering kunnen door verschillende factoren ontstaan. Een server gaat kapot, een applicatie kan de drukte niet aan, URL’s zijn niet meer bereikbaar doordat ze verwijderd zijn. Een webapplicatie die niet werkt is de nachtmerrie van veel ontwikkelaars, OOP kan hen helpen vaster te slapen. Een goed geschreven class vangt zijn eigen fouten af en slaat deze op als uitzondering (exception in het engels) in een apart hiervoor aangemaakt object. De ontwikkelaar kan vervolgens aan het einde van zijn script deze uitzonderingen opvangen (catch in het engels) en deze naar wens afhandelen10. Dit heeft als positieve invloed op de integriteit van een applicatie dat het script bij een fout niet stopt, maar doorgaat met uitvoeren. Door deze aanpak hoeft een kleine fout in het script of de code niet als gevolg te hebben dat een applicatie volledig stopt met functioneren De applicatie voert de overige programmatuur uit, waardoor de kans kleiner is dat de gebruiker een niet toonbare pagina voor zich ziet. Hierdoor wordt de applicatie betrouwbaarder en daarmee wordt de integriteit dus verhoogt. ON D E R H O U D B A A R H E I D In de hoofdstuk 1 is te lezen dat de reden voor het ontwikkelen van OOP de moeilijk onderhoudbare applicaties waren. De oplossing hiervoor, het opdeling van code in logische delen, heeft ertoe geleid dat stukken code makkelijker en sneller te lokaliseren zijn en deze beter leesbaar zijn. Een ander voordeel van de class hiërarchie, is dat een verandering op één plaats in de code niet meer tot gevolg heeft dat de rest van de applicatie niet meer werkt. Deze oplossingen zorgen ervoor dat een applicatie beter onderhoudbaar is. De logische opdeling is gedaan in classes waarin de functionaliteiten van de applicatie zijn opgeslagen. Doordat de code niet meer op één pagina staat, maar verdeelt is in classes, is een bepaald stuk code eenvoudig te lokaliseren en aan te passen wanneer dit nodig is. Doordat alle functionaliteit genesteld zit in de classes is het script voor de
21 | P a g i n a webapplicatie enkel een lijst van instructies aan die classes. Ook voor het script geldt daarom dat een bepaalde script makkelijker te lokaliseren en aan te passen is. Het is goed gebruik bij OOP om methodenamen te gebruiken die de werking van de methode duidelijk omschrijven. Wanneer Lisa een zeehond eet zal dit als volgt geschreven worden: $ijsbeer1->eet('zeehond'); Op deze manier wordt het script beter leesbaar omdat deze op spreektaal lijkt. Dit heeft als voordeel dat uit het script kan worden opgemaakt wat er met een object gebeurt, waardoor een deel van het script of de code sneller te lokaliseren is. Deze lokalisatie is nodig wanneer aanpassingen moeten worden gedaan aan de applicatie. Webapplicaties hebben functionaliteiten die niet werken, scripts draaien traag, of een applicatie moet uitgebreid worden. Wanneer een procedureel ontwikkelaar iets aan moet passen in zijn script, wat functionaliteit betreft, moet hij dit vaak op meerdere plaatsen doen. Dit komt doordat er bij de procedurele manier van programmeren veel geknipt en geplakt wordt in het script, waardoor hetzelfde stuk code vaak op meerdere plaatsen in het script voor komt. Daarnaast komt het bij procedureel programmeren vaak voor dat de uitkomst van één functie invloed heeft op een volgende. Hierdoor kan het aanpassing van een functie tot gevolg hebben dat een andere niet meer werkt en is de kans op fouten in de applicatie hoog. Het gebruik van OOP biedt hiervoor uitkomst en maakt het makkelijker om fouten op te lossen of een applicatie uit te breiden. Een goed opgezet OOP project zit zo in elkaar dat iedere class zoveel mogelijk op zichzelf staat, dit wordt ‘loose coupling’ genoemd. Deze opzet zorgt ervoor dat een aanpassing van de applicatie maar op één plaats gedaan hoeft te worden, namelijk in de desbetreffende class. Door het gebruik van loose coupling zal de aanpassing geen effect hebben op de rest van de applicatie. Dit draagt bij aan de integriteit van de applicatie en maakt deze beter onderhoudbaar.
SC H A A L B A A R H E I D Een loosly coupled class verhoogt niet alleen de integriteit van een applicatie maar vergroot ook de schaalbaarheid (reusability in het engels). Schaalbaarheid kan op 2 vlakken plaatsvinden, namelijk binnen en buiten een project. Schaalbaarheid binnen een project kan behaald worden door classes zo op te zetten dat een aanpassing van de code, geen domino‐effect heeft op de rest van de applicatie. Deze opzet wordt bereikt door een class specifieke taken te geven en deze zo op te zetten dat hij niet afhankelijk is van een andere class. Dit is duidelijk te maken aan de hand van een voorbeeld dat twee classes beschrijft. De eerste class stuurt een query naar een database en stuurt het resultaat in een array door naar de tweede class. Deze toont op zijn beurt de resultaten van de query. Wanneer de ontwikkelaar gebruik wil maken van een andere database, past hij dit aan in de eerste class. Dit levert geen problemen op voor de tweede class zo lang er maar een array met resultaten doorgestuurd wordt11. Schaalbaarheid buiten een project kan behaald worden door classes zo te schrijven dat ze niet projectspecifiek zijn. Een OOP ontwikkelaar moet zich bij iedere class die hij schrijft, afvragen of hij deze functionaliteiten ook in een ander project zou kunnen gebruiken. Wanneer dat het geval is, moet hij deze zoveel mogelijk loosely coupled schrijven. Dit heeft als gevolg dat de schaalbaarheid van een applicatie omhoog gaat en productietijd ervan omlaag. Het schrijven van een goede class kost veel ervaring, denkwerk en tijd. Een manier om die investering terug te verdienen is een class zo te schrijven dat een ontwikkelaar hem in meerdere projecten kan gebruiken12. Specifieke taken schrijven voor een class en tegelijkertijd deze class niet projectspecifiek maken, klinkt tegenstrijdig. Toch is het wat een OOP ontwikkelaar zoveel mogelijk na moet streven om de schaalbaarheid van zijn project zo groot mogelijk te maken.
23 | P a g i n a SA M E N V A T T I N G Om een goed beeld te schetsen van OOP ben ik in dit hoofdstuk dieper ingegaan op de mogelijkheden ervan en welke voordelen het met zich meebrengt. Om te beginnen heb ik een uitgebreidere uitleg gegeven over de class hiërarchie van OOP. Het opdelen van code is namelijk niet alleen ter bevordering van de onderhoudbaarheid van de applicatie. Het gebruik van classes biedt de ontwikkelaar namelijk ook mogelijkheden als overerving en interfaces. Deze toepassingen dragen bij aan de schaalbaarheid en integriteit van de applicatie. Het vergroten van die integriteit zit echter niet alleen in het gebruik van overerving of interfaces, ook inkapseling en foutafhandeling dragen daaraan bij. Het juist toepassen van inkapseling zorgt ervoor dat de data binnen een applicatie veilig en op de juiste plaats wordt opgeslagen. De mogelijkheden die OOP biedt voor foutafhandeling zorgen ervoor dat de fouten in een applicatie aan de ontwikkelaar worden doorgegeven, terwijl de gebruiker zo weinig mogelijk merkt van de fout. Vervolgens kan de ontwikkelaar de nodige actie ondernemen om de fout op te lossen. Dat aanpakken van fouten is met een object georiënteerde aanpak snel en eenvoudig te doen. Door de opzet van OOP is het voor de ontwikkelaar eenvoudiger om te achterhalen waar de fout zit in zijn code. Vervolgens kan hij die code snel terug vinden en indien hij zijn applicatie goed heeft opgezet, hoeft hij deze maar op één plaats aan te passen. Dat de ontwikkelaar zijn aanpassing maar op één plaats door hoeft te voeren komt doordat de classes van zijn applicatie onafhankelijk van elkaar zijn. De classes zijn niet alleen onafhankelijk van elkaar geschreven om fouten makkelijk op te kunnen lossen, maar ook om de schaalbaarheid van een project te vergroten. Wanneer de classes onafhankelijk van elkaar zijn, kunnen deze zonder aanpassing gebruikt worden in een ander project. Hiermee kan de ontwikkelaar de tijd die hij in het opzetten van een class heeft gestoken terugverdienen. In dit hoofdstuk ben ik dieper ingegaan op de definitie die ik in hoofdstuk 1 heb voorgelegd. Ik heb uitleg gegeven over welke voordelen het logisch opdelen van code met zich meebrengt en welke termen daarbij horen. Daarna heb ik uitleg gegeven over waarmee en waarom de integriteit van de applicatie vergroot wordt. Waarmee en
waarom de onderhoudbaarheid beter wordt bij OOP. Vervolgens heb ik uitleg gegeven over de voordelen van schaalbaarheid binnen en buiten een project. Nu lijkt het alsof OOP alleen voordelen kent, waarom bestaat er dan nog een procedurele aanpak? Buiten dat het aanleren van OOP veel tijd kost is het voor een ontwikkelaar belangrijk om te begrijpen wanneer hij gebruik moet maken van deze aanpak. In het volgende hoofdstuk wijs ik de ontwikkelaar daarom op de overwegingen die een OOP ontwikkelaar moet maken en waar hij rekening mee moet houden.
25 | P a g i n a
4 .
V
A L K U I L E NOOP wordt steeds vaker gebruikt door ontwikkelaars voor webapplicaties die geschreven zijn in PHP. De aanpak biedt de ontwikkelaar vele voordelen. Toch blijkt dat in de praktijk nog niet alle ontwikkelaars hun applicaties object georiënteerd programmeren en dat komt niet altijd door hun gebrek aan kennis. Het is de verantwoordelijkheid van de ontwikkelaar, erop te letten dat hij niet onnodig veel gebruik maakt van OOP. Een project kan te object georiënteerd worden, wanneer het doel van deze aanpak uit het oog verloren wordt. Dit doel heb ik omschreven als het logisch opdelen van code, ten goede van de onderhoudbaarheid, schaalbaarheid en integriteit. Wanneer een ontwikkelaar doelloos gebruik maakt van OOP, kan dit twee mogelijke verklaringen hebben, namelijk een praktische en een persoonlijke. PR A K T I S C H E R E D E N E N In sommige gevallen weet een ontwikkelaar niet wanneer hij wel en niet gebruik moet maken van een class. Deze groep kan in tweeën gedeeld worden. Enerzijds zijn er de ontwikkelaars die te weinig ervaring hebben op het gebied van OOP. Anderzijds zijn er de OOP fanaten. Uit hoeveel mensen deze laatste groep bestaat is moeilijk vast te stellen, maar dat het er veel zijn blijkt uit de grote aantallen discussies die zij voeren op het internet. Deze fanaten zijn te herkennen aan hun overmatig gebruik van classes. Het liefst zetten zij alles in een aparte class, zonder daarvoor een reden te kunnen geven. Ten tweede kan het overmatig gebruik van classes komen doordat er niet goed nagedacht is over de schaalbaarheid van het project. Het komt geregeld voor dat een ontwikkelaar zich onbedoeld schuldig maakt aan het overmatig gebruik van classes. David Powers beschrijft dit in zijn boek over object georiënteerde toepassingen als ‘It can feel like building a steamhammer to crack a hazelnut’13. Hiermee doelt Powers op de situatie waarin een ontwikkelaar voor een simpele taak een uitgebreide class aan het schrijven is. Dit doet de ontwikkelaar ondanks dat hij weet dat de functionaliteit niet elders nodig is en hij deze class niet kan gebruiken in andere projecten. In dit geval ligt het overmatig gebruik bij het gebrek aan schaalbaarheid.
Het is voor een ontwikkelaar uiterst belangrijk om in de gaten te houden of zijn project schaalbaar is. Kan het zijn dat er in de toekomst nog aanpassingen of uitbreidingen op dit project komen? En kunnen er voor dit specifieke project classes geschreven worden die mogelijk ook te gebruiken zijn in andere (toekomstige) projecten. Wanneer één van de bovenstaande vragen positief beantwoord kan worden, is het verstandig gebruik te maken van OOP. Wanneer beide vragen negatief beantwoord worden, is er op het gebied van schaalbaarheid geen behoefte aan OOP. In dat geval kan het zo zijn dat er voor een project toch voor de object georiënteerde aanpak gekozen wordt. Dit kan komen doordat de persoonlijke voorkeur van een ontwikkelaar meeweegt bij deze beslissing. PE R S O O N L I J K E V O O R K E U R De persoonlijke voorkeur van een ontwikkelaar kan tot gevolg hebben dat er bij de ontwikkeling van een webapplicatie gebruik wordt gemaakt van OOP, terwijl dit niet past bij het doel ervan. Deze persoonlijke voorkeur kan voortkomen uit ervaring met andere programmeertalen. Wanneer een ontwikkelaar JAVA code heeft geschreven voor hij met PHP begon is het aannemelijk dat hij kiest voor een object georiënteerde aanpak. JAVA is namelijk een zeer strikte, object georiënteerde taal. Omdat de ontwikkelaar gewend is aan deze manier van programmeren zal hij ervoor kiezen gebruik te maken van OOP. Daarnaast kan ook meespelen dat een ontwikkelaar de voorkeur geeft aan strikte regels tijdens het programmeren wat betreft naamgeving van functies, variabelen en classes. Deze striktheid is zowel toe te passen in procedureel als object georiënteerd programmeren. Bij OOP is het echter gebruikelijk (good practice) je aan strikte regels te houden, terwijl dit bij procedureel programmeren veel minder het geval is. Vandaar dat ontwikkelaars die hieraan de voorkeur geven vaak kiezen voor OOP. Deze aanpak is netjes, maar in sommige gevallen omslachtig of traag. Wanneer een ontwikkelaar een kleine applicatie moet bouwen met een minimaal aantal functionaliteiten welke hij niet in een ander project zal gebruiken, is het gebruik van OOP omslachtig te noemen. De ontwikkelaar hoeft bij de ontwikkeling van deze applicatie geen rekening te houden met onderhoud, schaalbaarheid of integriteit en daarmee heeft het gebruik van OOP geen nut.
27 | P a g i n a De persoonlijke voorkeur van een ontwikkelaar kan er echter ook voor zorgen dat een ontwikkelaar juist niet kiest voor het gebruik van OOP, waar dit technische gezien betere mogelijkheden biedt. Ook hier geldt dat ervaring een rol kan spelen. Wanneer een ontwikkelaar C code heeft geschreven voor hij gebruik ging maken van PHP, is hij meer bekend met de procedurele aanpak. Vandaar dat hij er eerder voor zal kiezen om zijn code procedureel te schrijven. En zoals er ontwikkelaars zijn die graag volgens strikte regels werken, zijn er ook die dit juist liever niet hebben. Dit kan ten kosten gaan van de onderhoudbaarheid van de applicatie. Dat maakt deze aanpak snel maar slordig. Als ontwikkelaar van webapplicaties is het van belang om zo neutraal mogelijk te blijven en geen persoonlijk voorkeur te ontwikkelen. Bij elke class die een ontwikkelaar bedenkt moet hij zichzelf afvragen wat de voordelen ervan zijn. TE C H N I S C H R E D E N E N Een OOP‐ontwikkelaar in sommige gevallen ook gedwongen worden om geen gebruik te maken van de object georiënteerde aanpak van ontwikkelen. Een voorbeeld hiervan is een Multi environment waarvoor een ontwikkelaar zijn applicatie moet maken. Omdat in de versies 3, 4 en 5 van PHP niet alleen de mogelijkheden, maar ook de syntax van OOP veranderde, is het zeer omslachtig een object georiënteerde applicatie te schrijven die op verschillende versies van PHP kan draaien. Wanneer een ontwikkelaar een applicatie moet maken die op verschillende versies moet kunnen draaien is het dus in veel gevallen een logische keuze om te gaan voor een procedurele aanpak.
SA M E N V A T T I N G In dit hoofdstuk heb ik uitleg gegeven over wat beweegredenen kunnen zijn van een ontwikkelaar om, al dan niet, te kiezen voor het gebruik van OOP. Ik vind het belangrijk om stil te staan bij welke aspecten deze keuze kunnen beïnvloeden om zo de lezer bewust te maken van de valkuilen die er zijn. Ik heb tijdens mijn onderzoek weinig kunnen vinden over waarom een ontwikkelaar, vanwege puur technische redenen, geen gebruik kan maken van OOP. Het enige wat hierbij naar voren kwam is het ontwikkelen van een applicatie die op verschillende versies van PHP moet kunnen draaien. Zelfs hierbij is het niet onmogelijk om dit object georiënteerd aan te pakken, maar in de meeste gevallen zal gekozen worden voor een procedurele aanpak. Praktische overwegingen om geen gebruik te maken van OOP zijn er genoeg. Samengevat is het gebruik van OOP voor het ontwikkelen van een applicatie niet praktisch wanneer de keuze niet aansluit bij het doel van OOP. Dit doel is het opdelen van code, ten goede van onderhoudbaarheid, schaalbaarheid en integriteit. Het doel kan uit het oog verloren worden door onkunde van de ontwikkelaar of doordat een ontwikkelaar zich laat beïnvloeden door zijn persoonlijke voorkeur of die van anderen.
29 | P a g i n a
5 .
C
O N C L U S I EIn de inleiding vertel ik dat de vraag die veel procedurele ontwikkelaars hebben gebruikt is als onderzoeksvraag. Dit is namelijk ook wat ik al lange tijd wilde weten. Die vraag luidt: “Wat heeft OOP mij te bieden?”. Waarop ik na grondig literatuuronderzoek en onderzoek in de beroepspraktijk het volgende antwoord heb geformuleerd. Wanneer de mogelijkheden van OOP op een verstandig wijze worden toegepast, maakt dat een applicatie beter onderhoudbaar en wordt de schaalbaarheid en integriteit ervan verhoogd. Het gebruik ervan werkt dus in het voordeel van de ontwikkelaar. Daarom zou ik iedere ontwikkelaar die zijn applicaties schrijft in PHP adviseren om zich te verdiepen in OOP. Dit advies komt ook voort uit het feit dat iedere ontwikkelaar, vroeg of laat, bewust of onbewust, in aanraking komt met OOP. Voor ontwikkelaars die helemaal niet thuis zijn in object georiënteerd programmeren is de eerste stap vaak een moeilijke. Deze scriptie geeft daarom inzicht in wat OOP inhoudt, welke mogelijkheden deze biedt en wat de valkuilen zijn waar de ontwikkelaar zich voor moet behoeden. Deze valkuilen zijn niet heel diep. Het belangrijkste om als ontwikkelaar in de gaten te houden is het doel van OOP, namelijk het bevorderen van onderhoudbaarheid, integriteit en schaalbaarheid. Wanneer een ontwikkelaar zijn applicatie object georiënteerd opzet zonder dat die aanpak bijdraagt aan één van bovengenoemde voordelen, maakt hij onnodig gebruik van OOP. Leer de techniek en gebruik deze wijs.
6 .
N
O T E N A P P A R A A T1 Bron 10 2 Powers 2008 p 4 3 Bron 11 4 Powers 2008 p 5 5 Zandstra 2008 p 15 6 Gebaseerd op Figure 1 http://www.adobe.com/devnet/director/articles/oop_dir_flash04.html 7 Lavin 2006 p 7 8 Lavin 2006 p 8 9 Powers 2008 p 26 10 Zandstra 2008 p 55‐59 11 Powers 2008 p 12 12 Lavin 2006 p 3 13 Powers 2008 p 20
31 | P a g i n a
