Wanneer is het nuttig om OOP te gebruiken?
Ik ben al een aantal jaar bezig met PHP, en ben er ondertussen redelijk handig mee. Ik kom geregeld scripts tegen met classes en dus geschreven in OOP. Nu ben ik bekend met veel PHP-functies en manieren van het schrijven van scripts, en het lezen en begrijpen van classes lukt, maar ik was benieuwd of iemand mij het grote voordeel van het schrijven hiervan kan uitleggen.
Ik begrijp dat je denkwijze aangepast moet worden en dat je door iets OOP te scripten het vervolgens als je het goed hebt gedaan daarna probleemloos zou kunnen hergebruiken. Dat klinkt natuurlijk goed: je hoeft een bepaalde classe dan maar 1 keer te schrijven en daarna in je volgende project gemakkelijk overnemen.
Wanneer je je gaat verdiepen in OOP kom je tutorials tegen met omschrijvingen als "denk aan een auto, die bestaat ook uit verschillende elementen die samenwerken", of "het menselijk lichaam" waar je eten in moet stoppen om te blijven functioneren.
Mijn vraag is dan ook: voor welke toepassing is het ideaal om Object Oriented te programmeren? Wie heeft er een goed voorbeeld of een link naar een goede tutorial zodat het voor iedereen, met name beginnende PHP'ers, gelijk duidelijk is wat het nut is om deze denkwijze aan te wennen? Wanneer zou je dus een classe met methods gaan gebruiken in plaats van een simpele functie?
Ik hoop op positieve reacties, er wordt op deze website al genoeg tegen elkaar gezeurd over slechte scripts, voorbeelden en reacties, ik hoop dat dit in dit topic niet voor hoeft te komen. Mijn vraag is serieus en ik denk dat redelijk wat mensen iets aan goede voorbeelden kan hebben.
Alvast bedankt,
Johan.
Sorry voor bump, maar dan houd ik 'm bij mijn laatste forumactiviteiten. Ik ben ook benieuwd naar de topics. Laatst vroeg ik me af of ik ook over moest gaan op OOP (met mijn half jaar PHP ervaring :P). Dit omdat ik toch al behoorlijke scripts maak.
roel schreef op 02.06.2009 19:24:
Kun je dat geintje niet eens afleren? Bookmark dan het topic of iets dergelijks, maar geef niet steeds nutteloze reacties.Goede vraag Johan.
Sorry voor bump, maar dan houd ik 'm bij mijn laatste forumactiviteiten.
Sorry voor bump, maar dan houd ik 'm bij mijn laatste forumactiviteiten.
Johan schreef:
Mijn vraag is dan ook: voor welke toepassing is het ideaal om Object Oriented te programmeren?
De grote voordelen van het programmeren in een objectgeorienteerd model (MVC danwel een ander patroon) zijn de herbruikbaarheid, schaalbaarheid en overzichtelijkheid van je code.
Zelf programmeer ik in het MVC model, en dat model is tegelijk ook het meest gebruikte als het om OO programmeren gaat. Je gaat meestal OO doen omdat je begint aan een wat grotere applicatie, die ook schaalbaar en overzichtelijk moet zijn.
Voor kleinere scripts zou ik er niet voor kiezen om alles OO te doen, omdat je dan vaak meer tijd kwijt bent met het maken van het OO model dan dat je bezig bent met de daadwerkelijke applicatie. Bij een grotere app is dat niet het geval.
Persoonlijk vind ik dat er niet echt goede tutorials over MVC te vinden zijn, waarin van begin tot eind wordt uitgelegd hoe het patroon werkt. Ik kan je aanraden om een MVC framework te downloaden dat al werkt. Denk aan CodeIgnitir, Zend Framework of CakePHP. Ook kleinere frameworks/frameworks die nog sterk ontwikkeld worden zijn goed om te bekijken (vaak ook nog wat overzichtelijker), bijvoorbeeld het Adroit framework (overigens geen documentatie).
Accepteer voor jezelf dat het je weken, misschien maanden zal kosten om het MVC idee volledig onder de knie te krijgen en in staat te zijn om zelf naar het model te programmeren. Hou daarbij in je hoofd dat wanneer het zover is, je prachtige, moderne applicaties kunt bouwen met alle voordelen die MVC met zich meebrengt.
OOP is eigenlijk altijd nuttig. het scheelt enorm veel code en maakt je applicatie vele malen inzichtelijker (niet allene voor jezelf maar ook voor anderen!).
Ik ben er zelf sinds kort mee begonnen nadat ik al aardig wat met OOP heb gedaan in Java en VB.NET. Ik moet zeggen dat het me (zeker sinds PHP 6) erg goed bevalt.
Als je PHP 4 gebruikt is het een afrader, daar werkt lang niet alles goed.
Als je wil leren over OOP in PHP6 kan ik je het boek "Professional PHP6" aanraden. een preview is te vinden op google books.
termination schreef op 02.06.2009 20:01:
PHP 6 is nog niet uit.Ik sluit me aan bij Midas en hipska.
OOP is eigenlijk altijd nuttig. het scheelt enorm veel code en maakt je applicatie vele malen inzichtelijker (niet allene voor jezelf maar ook voor anderen!).
Ik ben er zelf sinds kort mee begonnen nadat ik al aardig wat met OOP heb gedaan in Java en VB.NET. Ik moet zeggen dat het me (zeker sinds PHP 6) erg goed bevalt.
Als je PHP 4 gebruikt is het een afrader, daar werkt lang niet alles goed.
Als je wil leren over OOP in PHP6 kan ik je het boek "Professional PHP6" aanraden. een preview is te vinden op google books.
OOP is eigenlijk altijd nuttig. het scheelt enorm veel code en maakt je applicatie vele malen inzichtelijker (niet allene voor jezelf maar ook voor anderen!).
Ik ben er zelf sinds kort mee begonnen nadat ik al aardig wat met OOP heb gedaan in Java en VB.NET. Ik moet zeggen dat het me (zeker sinds PHP 6) erg goed bevalt.
Als je PHP 4 gebruikt is het een afrader, daar werkt lang niet alles goed.
Als je wil leren over OOP in PHP6 kan ik je het boek "Professional PHP6" aanraden. een preview is te vinden op google books.
Om even te reageren op Midas: bedankt voor je duidelijke uitleg. Ik ben enigszins bekend met bijvoorbeeld Zend, maar voor mijn gevoel vind ik het prettiger om een applicatie grotendeels zelf te schrijven boven het gebruik van een compleet framework. Een mogelijk nadeel van bijvoorbeeld Zend vind ik dat de library zelf zo'n 18 Mb is, dat onderdelen die je gebruikt mogelijk anders worden bij een volgende release van het framework en dat je afhankelijk bent van de manieren waarop de dingen gedaan worden. Ik bedoel: je moet je gaan verdiepen in een specifiek gedeelte van een framework om deze vervolgens op een bepaalde manier te gaan toepassen. Als je zelf iets schrijft kost het meer tijd, daar ben ik het mee eens, maar alles wat je er in stopt ga je ook zelf gebruiken. Dus iemand die begint te werken met bijvoorbeeld Zend zal eerst heel veel voorbeelden moeten bekijken en hieruit moeten kopiëren voordat je het zelf kan gaan gebruiken en schrijven.
Heb ik het fout of klopt het dat OOP-programmeren (zoals met classes en methods) je niet per se een framework hoeft te gebruiken? Om het voor mezelf even duidelijk te hebben: het feit dat je volgens een OOP-methode gaat programmeren zegt niet dat je per se een framework van iemand anders moet gaan gebruiken?
Gewijzigd op 01/01/1970 01:00:00 door Johan M
Je maakt een klasse die bepaalde eigenschappen en functies heeft en die je instantieerd.
bijvoorbeeld klasse vogel.
een vogel kan fluiten en vliegen.
de eigenschappen zijn bijvoorbeeld staartlengte, soort en kleur.
dan krijg je iets als het volgende (pseudo-code!)
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
<?php
class vogel {
private $_staartlengte; // de _ is er om aan te duiden dat het ene private is.
private $_soort;
private $_kleur;
public funciton tjilp(){
echo "tjilp!"; // laat de vogel tjilpen
}
public function getSoort(){
return $this->_soort;
}
// en zo verder voor alle private memebers
}
// nu de vogel maken
$mees = new vogel;
$mees->tjilp;
?>
class vogel {
private $_staartlengte; // de _ is er om aan te duiden dat het ene private is.
private $_soort;
private $_kleur;
public funciton tjilp(){
echo "tjilp!"; // laat de vogel tjilpen
}
public function getSoort(){
return $this->_soort;
}
// en zo verder voor alle private memebers
}
// nu de vogel maken
$mees = new vogel;
$mees->tjilp;
?>
dit zal als resultaat geven "tjilp!";
lijkt niet nuttig voor zo weinig code, maar met meer is het echt heel erg handig!
Gewijzigd op 01/01/1970 01:00:00 door Thom nvt
Johan schreef op 02.06.2009 20:06:
In principe niet. Je kan ten eerste het framework zelf maken, wat ik je aanraad omdat het heel leerzaam is. Ik denk dat je bedoelt of je überhaupt een framework moet gebruiken om OO te programmeren? Het antwoord is nee.PHP4 is sowieso een afknapper, persoonlijk vind ik 5 een minimum. (Edit: en inderdaad de standaard omdat 6 nog niet uit is zoals hierboven aangegeven.)
Om even te reageren op Midas: bedankt voor je duidelijke uitleg. Ik ben enigszins bekend met bijvoorbeeld Zend, maar voor mijn gevoel vind ik het prettiger om een applicatie grotendeels zelf te schrijven boven het gebruik van een compleet framework. Een mogelijk nadeel van bijvoorbeeld Zend vind ik dat de library zelf zo'n 18 Mb is, dat onderdelen die je gebruikt mogelijk anders worden bij een volgende release van het framework en dat je afhankelijk bent van de manieren waarop de dingen gedaan worden. Ik bedoel: je moet je gaan verdiepen in een specifiek gedeelte van een framework om deze vervolgens op een bepaalde manier te gaan toepassen. Als je zelf iets schrijft kost het meer tijd, daar ben ik het mee eens, maar alles wat je er in stopt ga je ook zelf gebruiken. Dus iemand die begint te werken met bijvoorbeeld Zend zal eerst heel veel voorbeelden moeten bekijken en hieruit moeten kopiëren voordat je het zelf kan gaan gebruiken en schrijven.
Heb ik het fout of klopt het dat OOP-programmeren (zoals met classes en methods) je niet per se een framework hoeft te gebruiken? Om het voor mezelf even duidelijk te hebben: het feit dat je volgens een OOP-methode gaat programmeren zegt niet dat je per se een framework van iemand anders moet gaan gebruiken?
Om even te reageren op Midas: bedankt voor je duidelijke uitleg. Ik ben enigszins bekend met bijvoorbeeld Zend, maar voor mijn gevoel vind ik het prettiger om een applicatie grotendeels zelf te schrijven boven het gebruik van een compleet framework. Een mogelijk nadeel van bijvoorbeeld Zend vind ik dat de library zelf zo'n 18 Mb is, dat onderdelen die je gebruikt mogelijk anders worden bij een volgende release van het framework en dat je afhankelijk bent van de manieren waarop de dingen gedaan worden. Ik bedoel: je moet je gaan verdiepen in een specifiek gedeelte van een framework om deze vervolgens op een bepaalde manier te gaan toepassen. Als je zelf iets schrijft kost het meer tijd, daar ben ik het mee eens, maar alles wat je er in stopt ga je ook zelf gebruiken. Dus iemand die begint te werken met bijvoorbeeld Zend zal eerst heel veel voorbeelden moeten bekijken en hieruit moeten kopiëren voordat je het zelf kan gaan gebruiken en schrijven.
Heb ik het fout of klopt het dat OOP-programmeren (zoals met classes en methods) je niet per se een framework hoeft te gebruiken? Om het voor mezelf even duidelijk te hebben: het feit dat je volgens een OOP-methode gaat programmeren zegt niet dat je per se een framework van iemand anders moet gaan gebruiken?
Je kunt gewoon OO programmeren zonder ook maar met een framework te maken te hebben. Als jij een class maakt en daar wat dingen mee doet dan ben je in principe OO bezig. Maar vaak zul je toch wel gaan neigen naar het MVC model, en dan heb je een hele specifieke manier van het afhandelen van een request naar een webpagina, namelijk met een zogeheten Frontcontroller, ook wel Router genoemd.
Je kunt deze classes (Frontcontroller, database klasses, ed) zelf gaan maken, maar ze zijn ook al voor je gemaakt. Als je een setje van die klassen gebruikt praten we dus over een framework. Natuurlijk kun je dit dan ook zelf maken, en dan heb je dus je eigen framework.
Naar een antwoord van deze strekking was ik inderdaad meer op zoek, een stukje code waarmee het voor mij duidelijker wordt wàt je met OO-programmeren in PHP kan. Echter post je nu een vogel, en zoals ik in mijn eerste post schreef is dit niet precies wat ik zoek. Een vogel-voorbeeld is hetzelfde als een auto of een mens, maar hiermee wordt het niet duidelijk voor de beginnende OOP'er wàt je er nou precies mee kan.
Om het misschien te verduidelijken: stel je maakt een forum, gastenboek, pm-systeem, login-systeem of verzin het maar, heb je dan een voorbeeld wat er in een van deze applicaties of scripts nu ideaal is om in OO te schrijven?
@ Midas: ok, dit begrijp ik. Uiteraard is het niet mijn bedoeling om het wiel opnieuw uit te vinden en ik ben bereid me te verdiepen in het MVC-model. Zoals je zelf aangaf: "persoonlijk vind ik dat er niet echt goede tutorials over MVC te vinden zijn", wat dit dan weer lastig maakt.
Grz. Johan.
Gewijzigd op 01/01/1970 01:00:00 door Johan M
Midas schreef op 02.06.2009 19:44:
Bij een grotere app is dat niet het geval.
Wat voor voorbeelden geef je bij een grotere app?
Midas:
Je kunt deze classes (Frontcontroller, database klasses, ed) zelf gaan maken, maar ze zijn ook al voor je gemaakt. Als je een setje van die klassen gebruikt praten we dus over een framework. Natuurlijk kun je dit dan ook zelf maken, en dan heb je dus je eigen framework.
Je kunt deze classes (Frontcontroller, database klasses, ed) zelf gaan maken, maar ze zijn ook al voor je gemaakt. Als je een setje van die klassen gebruikt praten we dus over een framework. Natuurlijk kun je dit dan ook zelf maken, en dan heb je dus je eigen framework.
Wat voor standaard classes zitten er in het algemeen in een framework?
Gewijzigd op 01/01/1970 01:00:00 door Roeltje M
Voor de mensen die met OOP willen beginnen raad ik niet aan om meteen alles in classes te gieten maar begin bij simpele objecten.
Bijvoorbeeld: user, gastenboekbericht, nieuwsbericht, reactie, activiteit, ...
Als je deze dingen eenmaal goed kan, kan je gaaan uitbreiden.
Maar: als de toepassingen die ik noem niet per definitie goed zijn om te gaan maken door middel van OO, wat zou je er dan wel mee gaan maken?
Dit is dus een moeilijkheid bij het lezen van tutorials hierover, je krijgt voorbeelden van auto's, fietsen, mensen of vogels, maar wat ik wil maken (en al maak, maar dan zonder OOP) zijn dus dingen als een login-systeem, gastenboek, forum e.d. Wat zou mijn voordeel zijn om het vanuit het OOP-principe te gaan scripten en op welke onderdelen zou het van toepassing zijn?
Bijvoorbeeld het plaatsen van een bericht in een gastenboek. Daarbij moet eerst gecontroleerd worden of er een bericht is opgestuurd, daarna of de inhoud geldig is, ook of het niet een spambericht is, en als dat allemaal goed is, moet het bericht worden toegevoegd aan het gastenboek. Vroeger, voor de functies, zou je nu al een hele lap code hebben. Maar dit probleem kan je in weze oplossen met slechts 4 functies. Het implementeren van die functies doe je daarna. Je deelt je grote probleem (hoe sla ik een bericht op wanneer iemand dat instuurt) op in kleinere stukjes.
Object geörienteerd programmeren is dat, en dan een stapje verder. In het voorbeeld met functies had ik het nog over een bericht, maar wat is dat bericht dan precies? Waarschijnlijk zou je standaard een tal variabelen los van elkaar hebben (eentje met een emailadres, eentje met de inhoud, etc) maar dan ben je weer bezig met details. Dus introduceren we de klasse Bericht. Een instantie van Bericht representeert, jawel, een bericht uit het gastenboek.
Voor mij is OO programmeren eerst programmeren op een hoger niveau, waarbij je nog niet alle details (de queries, de validatie-functies, etc.) hoeft uit te denken. Heb je dat klaar (dan kan je dat testen met dummy-data :) ) dan ga je naar een lager niveau, en ga je de details op dezelfde manier implementeren. En dan ga je de details daarvan weer implementeren, en zo ga je door totdat je weer met beide benen op de grond staat, en alleen nog maar standaard PHP functies aanroept.
Je kan dus prima OO programmeren zonder bibliotheken van anderen, maar de methode nodigt uit tot het gebruik van de bibliotheken van anderen. Zij hebben dan al zo'n detail helemaal voor je uitgewerkt, en die kan je dan gebruiken. Bevalt je die implementatie achteraf niet, dan werk je het detail opnieuw uit, maar de andere details hoef je dan niet meer aan te zitten, die zijn onafhankelijk (zolang je de interface van je details maar niet verandert, dwz de functie/method-namen, argumenten en waarden die ze teruggeven aan het hogere niveau)
Om jezelf in bescherming te nemen dat je niet details met elkaar gaat verweven heb je dingen als data hiding in OOP.
OOP komt met een keerzijde overigens. Omdat je op zo'n hoger niveau werkt, met data hiding en eigen verantwoordelijkheid van klassen moet je gaan nadenken over hoe je je klassen met elkaar gaat verbinden, hoe ze toegang kunnen krijgen tot dat wat ze nodig hebben (hoe kan de klasse/functie die de berichten opslaat bij de klasse (PDO bijv.) die verbinding heeft met de database?)
PHP heeft trouwens het (naar mijn mening) voordeel dat je procedureel programmeren en object geörienteerd programmeren heerlijk met elkaar kan mengen. Doe dat ook, vooral in het begin. In het voorbeeld van het gastenboek zou ik Bericht wel een klasse maken, maar het gastenboek zou ik in eerste instantie beheren met functies. (voeg_bericht_toe(Bericht $bericht), haal_berichten_op()) Daarna zal je geleidelijk door krijgen dat globale objecten, zoals de database verbinding die je dan globaal nodig hebt omdat die functies daarvan afhankelijk zijn, best gevaarlijk kunnen zijn (omdat je ze zomaar kan veranderen) en dat het misschien wel beter is om een aparte klasse te maken die Bericht-instanties in en uit de database haalt. En zo kan je geleidelijk meer dingen met objecten doen. Maar vooral in het begin zou ik niet in het MVC bootje springen, en verder gaan waar je nu met procedureel programmeren bent: mixen.
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
<?php
if(REQUEST_METHOD is POST)
{
$bericht = new Bericht();
$bericht->naam = $_POST['naam'];
$bericht->inhoud = $_POST['inhoud'];
if(!is_goed_bericht($bericht))
{
toon_melding('geen goed bericht');
toon_formulier($bericht);
}
if(is_spam_bericht($bericht))
{
toon_melding('spam');
toon_formulier($bericht);
}
else
{
voeg_bericht_toe($bericht);
toon_melding('bericht_toegevoegd');
}
}
toon_alle_berichten();
?>
if(REQUEST_METHOD is POST)
{
$bericht = new Bericht();
$bericht->naam = $_POST['naam'];
$bericht->inhoud = $_POST['inhoud'];
if(!is_goed_bericht($bericht))
{
toon_melding('geen goed bericht');
toon_formulier($bericht);
}
if(is_spam_bericht($bericht))
{
toon_melding('spam');
toon_formulier($bericht);
}
else
{
voeg_bericht_toe($bericht);
toon_melding('bericht_toegevoegd');
}
}
toon_alle_berichten();
?>
Hoplakee, een gastenboek :)
edit: In een grotere app zitten overigens vooral classes voor standaard-problemen: inloggen, rechten, formulieren afhandelen, database toegang, templates, conversie van dingen, etc. Maar juist in het begin is het misschien goed om zelf te ontdekken wat handig is. Is veel leuker!
Mijn tip trouwens: wees heel pragmatisch. Programmeer alleen wat je op dat moment nodig hebt, implementeer niet dingen die je later denkt nodig te hebben. Die fout heb ik een hele tijd gemaakt: het probleem algemener oplossen dan dat in de situatie nodig was, en daarmee krijg je hele ingewikkelde code en een niet-ideale oplossing. Het klinkt heel leuk, omdat je zo'n algemenere oplossing kan hergebruiken maar in de praktijk doe je dat niet omdat hij net niet geschikt genoeg is, of omdat je nieuwe ervaring hebt en nu beter weet hoe je het probleem kan oplossen.
Gewijzigd op 01/01/1970 01:00:00 door Jelmer -
http://phphulp.pastebin.com/f23a73657
http://phphulp.pastebin.com/ff982570
Bedankt voor je verhelderende uitleg, ik denk dat veel mensen, zowel beginners als iets gevorderde PHP'ers (die zich ook in OOP willen gaan verdiepen) er zeker iets aan zullen hebben!
Mocht je (of iemand anders) nog meer tips/snippets hebben om mij en anderen in het OOP op weg kunnen helpen, dan houd ik me beleefd aanbevolen.
Grz. Johan.
// Edit: @ Hipska: bedankt voor de links, ik ga ze bestuderen :P
Gewijzigd op 01/01/1970 01:00:00 door Johan M