[PHP] OOP of niet?

[DelTorro]

Ongeveer 5 weken geleden ben ik begonnen met het leren van PHP. Ondanks dat ik weinig ervaring heb met programmeren lukt dit al aardig.
Nu heb ik me laatst verdiept in OOP (met php dus) en dit lijkt me een geschikte manier van programmeren omdat het meer overzicht biedt t.o.v structureel programmeren en OOP-code over het algemeen herbruikbaar is. Er werd verteld dat OOP het meest geschikt is voor grote projecten, voor kleine projecten kan het juist onhandig zijn.
Nu ben ik continue bezig met mijn eigen website (vooral het toepassen van php-scripts). Nu is mijn vraag: is het in mijn geval verstandig nu al OOP met php aan te leren en op deze manier mijn website op te zetten? Uiteindelijk wil ik graag een CMS ontwikkelen en dan kan deze manier van programmeren me natuurlijk erg van pas komen.
Nadeel lijkt me het bovengenoemde argument dat voor kleine projecten (mijn website bijv.) OOP onhandig kan zijn.

[Erkens]

Ik zie niet in waarom OOP onhandig is met kleine projecten

[Cyphax]

Ik vind het altijd heel erg afhangen van wat je wilt maken. Kijk naar hoe je je CMS op gaat zetten, wellicht ga je al gauw neigen om een klassediagram te maken voor de structuur, en dan ben je ook al snel bezig met een OO aanpak.

[whoami]

Waarom is het onhandig voor kleine projecten, kan je dat beargumenteren ?

Ik denk dat het verstandiger is om OO te leren met een taal zoals Java , C# of C++.
Als je OO wilt leren, dan is het ook belangrijk om eens verder te kijken naar tutorials / boeken die echt ingaan op OO, en niet zozeer gericht zijn op een specifieke taal. In je PHP boek / tutorial zal je wel vinden wat een class is, wat abstract is, wat inheritance is, wat virtual methods zijn, enzo, en hoe je dat in PHP moet definieren, maar het zal er niet uitgelegd staan wanneer je wat moet gebruiken.

[DaRKie]

Onhandig is het niet echt, het is eerder meer werk voor een klein project (ook iets moelijker als je er pas mee begint).
Maar op termijn is een goed OO design tijdbesparend en het probleem van kleine projecten is dat ze kunnen groot worden en als je dan geen goed ontwerp heb...

[Johnny]

Het ligt ook aan de versie van PHP die je gebruikt, in PHP4 ontbreken veel eigenschappen van OOP nog, in PHP5 zit het een stuk beter in elkaar.

Maar dan nog blijft de vraag, heb je het nodig? Als je gewoon een aantal zelf geschreven functies die met elkaar te maken hebben in een PHP-bestandje zet dat je include kan je ze later ook makkelijk hergebruiken, het enige waar je dan op moet letten is dat je functies en globale variabelen niet per ongeluk dezelfde naam geeft.

[JKVA]

Zelfs in kleine projecten biedt OO significante voordelen t.o.v. procedureel programmeren, vooral omdat je zaken ECHT inkapselt en niet doet alsof ze ingekapseld zijn met een functie en (semi-)globale variabelen.

Bovendien leer je OO programmeren en designen niet 123. OO is een 'way of life'

[Genoil]

Ik vind dat TS zeker wel een punt heeft wat betreft de overhead die OOP geeft voor kleinere projecten. Voor m'n CMS gebruik ik echt alleen maar OOP in een (quasi-) MVC pattern, maar voor de frontendjes die ik er tegenaan plak gebruik ik de laatste tijd weer erg vaak "oldskool" PHP, gewoon lekker een paar includejes van wat handige functies en zich herhalende brokjes html, en voor de rest lekker alles bij elkaar in 1 bestand, alsof het 5 jaar geleden is toen ik begon met PHP.

[Erkens]

Genoil schreef op donderdag 30 maart 2006 @ 09:48:
Ik vind dat TS zeker wel een punt heeft wat betreft de overhead die OOP geeft voor kleinere projecten.

over wat voor overhead hebben we het hier?

[JKVA]

Erkens schreef op donderdag 30 maart 2006 @ 09:57:
[...]

over wat voor overhead hebben we het hier?

Dat is vaak een kwestie van gewenning, is mijn ervaring. Als ik even iets klus, (voor iemand anders die niet OO programmeert) is het vaak rechttoe rechtaan. Als ik OO programmeer heb ik vaak de neiging om TE netjes te werken, waardoor het meer tijd kost dan gepland en een overdosis klassen ontstaat die, op zich wel voordelen hebben, maar qua prijs/kwaliteit verhouding niet goed scoren.

Maar goed, daar heb je dan weer projectleiders en collega's voor.

[Genoil]

Erkens schreef op donderdag 30 maart 2006 @ 09:57:
[...]

over wat voor overhead hebben we het hier?

Nou als je dan OOP gaat gebruiken "moet" er natuurlijk ook altijd een fraai pattern tegenaan gegooid worden, wat bij dynamische PHP websites vaak neerkomt op MVC. Zo'n framework, zelf geschreven of niet, geeft gewoon overhead qua hoeveelheid code en de complexiteit ervan, en ook qua performance leidt je wat verlies omdat er veel meer dingen gedaan moeten worden, en zaken als afscherming en inkapseling kosten ook gewoon meer tijd.

Vooral bij (veelal read-only) webfrontends is al het fraaie wat OOP te bieden heeft allemaal niet zo nodig. Het leeuwedeel van de tijd die je aan zo'n frontend kwijt ben zit em toch in het opbouwen van de HTML en CSS. Het dynamische gedeelte komt vaak neer op niet veel meer dan een paar eenvoudige database queries en het ombouwen van de resultaten daarvan naar presenteerbare informatie is in de meeste gevallen gewoon bijna 1 op 1.

Ik kan er wel wel een FrontWebController tegenaan gooien, maar als er maar 1 View is en de Action is altijd "read" of "view", wat moet ik er dan mee? Fraaie foutafhandeling heb ik helemaal niet nodig, want dynamische PHP websitejes gaan gewoon meestal goed. En als er iets fout gaat, krijg ik de melding "Er is iets fout gegaan, probeer het later nog eens", ook wel in m'n templates zonder een ErrorDocument class.

[JKVA]

Genoil schreef op donderdag 30 maart 2006 @ 10:13:

Nou als je dan OOP gaat gebruiken "moet" er natuurlijk ook altijd een fraai pattern tegenaan gegooid worden, wat bij dynamische PHP websites vaak neerkomt op MVC. Zo'n framework, zelf geschreven of niet, geeft gewoon overhead qua hoeveelheid code en de complexiteit ervan, en ook qua performance leidt je wat verlies omdat er veel meer dingen gedaan moeten worden, en zaken als afscherming en inkapseling kosten ook gewoon meer tijd.

Waarom kost inkapseling meer tijd? Dat is toch iets dat je meteen doet? Eerstejaars op school maken altijd eerst de variabelen public om daarna alles te hernoemen naar getXxx(), maar als je het meteen goed inkapselt kost het geen extra tijd en levert het tijd op met testen.

Genoil schreef op donderdag 30 maart 2006 @ 10:13:
[...]

Vooral bij (veelal read-only) webfrontends is al het fraaie wat OOP te bieden heeft allemaal niet zo nodig. Het leeuwedeel van de tijd die je aan zo'n frontend kwijt ben zit em toch in het opbouwen van de HTML en CSS. Het dynamische gedeelte komt vaak neer op niet veel meer dan een paar eenvoudige database queries en het ombouwen van de resultaten daarvan naar presenteerbare informatie is in de meeste gevallen gewoon bijna 1 op 1.

Ik vind het persoonlijk wel fijn als zaken zoals SQL injection vast standaard voor me afgehandeld worden, zonder dat ik dat per pagina moet regelen. Je vergeet namelijk vrij snel een variabele en je hebt een beveiligingslek.

En zo zijn er nog wel wat redenen te bedenken om wel voor OO te gaan, ook bij kleine projecten

[Genoil]

JKVA schreef op donderdag 30 maart 2006 @ 10:25:
[...]


Waarom kost inkapseling meer tijd? Dat is toch iets dat je meteen doet? Eerstejaars op school maken altijd eerst de variabelen public om daarna alles te hernoemen naar getXxx(), maar als je het meteen goed inkapselt kost het geen extra tijd en levert het tijd op met testen.

Het kost meer processing tijd, zo'n 4 keer zoveel. Nou is dat natuurlijk ook niet zo'n big issue, maar toch. Daarnaast gaat inkapseling in PHP4 strict genomen natuurlijk helemaal nergens over . Als ik zelf met Model classes werk kost me overigens 0 extra tijd, aangezien al m'n model classes gegenereerd worden met templates.

[...]


Ik vind het persoonlijk wel fijn als zaken zoals SQL injection vast standaard voor me afgehandeld worden, zonder dat ik dat per pagina moet regelen. Je vergeet namelijk vrij snel een variabele en je hebt een beveiligingslek.

Ten eerste had ik het over publieke webfrontendjes, daar mogen ze wat mij betreft proberen te injecteren tot ze ons wegen, alle informatie erop is toch publiek. Dus ik regel gewoon niks! En anders gewoon ff addslashes(), zo'n moeite is dat toch ook weer niet?

Verder is het gewoon een kwestie van omschakelen naar een andere mind-set, waarin je veel minder op een abstract niveau bezig met met bergen classes die als het allemaal goed gaat allerlei zaken voor je afhandelen, maar veel 'dichter' op de code zit, veel meer uitgaat van bepaalde voorwaarden waaraan code moet voldoen om te werken, waardoor je minder bezig bent met foutafhandeling, overhead die ontstaat door het herbruikbaar maken van code en andere vertroebelende zaken die de klant in het uiteindelijke resultaat toch niet ziet.

En zo zijn er nog wel wat redenen te bedenken om wel voor OO te gaan, ook bij kleine projecten

Die zijn er zeker ook wel, ik ben ook helemaal niet anti-OOP. Ook in een klein project kan er bijvoorbeeld veel data-manipulatie voorkomen. Dan vind ik OOP echt wel prettig.

[JKVA]

Genoil schreef op donderdag 30 maart 2006 @ 11:03:
[...]
Ten eerste had ik het over publieke webfrontendjes, daar mogen ze wat mij betreft proberen te injecteren tot ze ons wegen, alle informatie erop is toch publiek. Dus ik regel gewoon niks! En anders gewoon ff addslashes(), zo'n moeite is dat toch ook weer niet?

Injecteren kan ook door te zeggen url.php?id=1;drop table naam;--

Verder zijn de meeste dingen niet moeilijk. Ik had het over het vergeten van code. En als je geen framework hebt ofzo die dat voor je doet, vergeet je het zo.

[Genoil]

JKVA schreef op donderdag 30 maart 2006 @ 12:06:
[...]


Injecteren kan ook door te zeggen url.php?id=1;drop table naam;--

Ja dat is ook weer waar, maar uiteindelijk gaat de discussie natuurlijk niet over het voorkomen van SQL injection

Verder zijn de meeste dingen niet moeilijk. Ik had het over het vergeten van code. En als je geen framework hebt ofzo die dat voor je doet, vergeet je het zo.

Een framework hoeft ook niet OOP te zijn. En OOP zorgt er ook niet voor dat je nooit meer code vergeet.

[JKVA]

Genoil schreef op donderdag 30 maart 2006 @ 12:56:
[...]
Een framework hoeft ook niet OOP te zijn. En OOP zorgt er ook niet voor dat je nooit meer code vergeet.

Daar heb je gelijk in, maar ik denk dat het wel moeilijker wordt om dingen te vergeten als je OO werkt.

[Verwijderd]

Ik denk dat je een balans moet hebben tussen middel en doel. Voor mijn eigen site bijvoorbeeld gebruik ik geen OOP. In het kort is dit alles wat ik doe:

PHP:

function getCV() {// haal cv op
}
function getLinks() { // haal links op
}

// zo nog een paar functies

$cv = getVC();
$links = getLinks();
// etc

En onderaan deze functies staat de html:

PHP:

<html> etc etc
<?= $cv ?>
<nog wat html>
<?= $links ?>
</html>

'T is 1 bestand, en doet precies wat ik wil. Ik kan natuurlijk ook een database class maken, een OOP templateparser en een class voor foutafhandeling, maar dan heiligt imo het doel het middel niet.

[mrFoce]

[rml][ php] Het nut van OO classes[/rml]

[Michali]

Ik zou snel mogelijk met OO aan de gang gaan. Je zult zien dat het veel logischer is en ook beter aansluit bij hoe je over bepaalde zaken denkt. In het begin is het moeilijk vertalen naar code (later ook wel, maar dan weet je beter je weg te vinden), maar dat komt vanzelf wel. Je doet er wel goed aan je een beetje in de princiepes te verdiepen en je aan een paar regels te houden. Daar is wel genoeg info over te vinden.

[mulder]

Verwijderd schreef op donderdag 30 maart 2006 @ 13:49:
Ik denk dat je een balans moet hebben tussen middel en doel. Voor mijn eigen site bijvoorbeeld gebruik ik geen OOP. In het kort is dit alles wat ik doe:

PHP:

function getCV() {// haal cv op
}
function getLinks() { // haal links op
}

// zo nog een paar functies

$cv = getVC();
$links = getLinks();
// etc

En onderaan deze functies staat de html:

PHP:

<html> etc etc
<?= $cv ?>
<nog wat html>
<?= $links ?>
</html>

'T is 1 bestand, en doet precies wat ik wil. Ik kan natuurlijk ook een database class maken, een OOP templateparser en een class voor foutafhandeling, maar dan heiligt imo het doel het middel niet.

Waarom gebruik je uberhaupt functies in dit voorbeeld?

[Verwijderd]

Omdat ik niet alle PHP tussen de html in wil hebben, vind dit overzichtelijker werken.

[JKVA]

Ik zou zeggen: "Ik heb een geteste databaseklasse, die gebruik ik dan mooi ook bij dit (kleinere) project, ondanks de eventuele overhead"

Het argument van performance vind ik overigens ook onzin, want hoeveel procent van de tijd gaat nou in dat stukje OO zitten? 1%? Nee, dan kun je beter een stel goede indexen op je database leggen en goede algoritmes gebruiken. (waar OO ook voordelen biedt met betrekking tot hergebruik en zo)

edit:

DB klasse is natuurlijk alleen maar als een eenvoudig voorbeeld bedoeld

[ Voor 11% gewijzigd door JKVA op 30-03-2006 19:52 ]

[Genoil]

JKVA schreef op donderdag 30 maart 2006 @ 19:52:
Ik zou zeggen: "Ik heb een geteste databaseklasse, die gebruik ik dan mooi ook bij dit (kleinere) project, ondanks de eventuele overhead"

Het argument van performance vind ik overigens ook onzin, want hoeveel procent van de tijd gaat nou in dat stukje OO zitten? 1%? Nee, dan kun je beter een stel goede indexen op je database leggen en goede algoritmes gebruiken. (waar OO ook voordelen biedt met betrekking tot hergebruik en zo)

edit:

DB klasse is natuurlijk alleen maar als een eenvoudig voorbeeld bedoeld

Ja misschien is het ook wel het feit dat ik voor de Model laag in m'n CMS een best wel bloated ORM laag gebruik waarvan de performance significant lager is dan het gebruik van platte MySQL queries en waarvan ik de functionaliteit aan de frontend nauwelijks nodig heb, dat ik voor een aantal projecten heb besloten het allemaal zo eenvoudig mogelijk aan te pakken en een simpel libje heb geschreven voor de frontends.

Daarnaast moet ik ook wel eens dingen maken die bijvoorbeeld gerelateerd zijn aan TV-uitzendingen, waardoor het soms behoorlijk kan pieken op de servers waar mijn programmatuur staat, dus dan is 400% (waar ik zelf in onderstaande wellicht niet geheel representatieve voorbeeld op kom), toch wel best een winst.

PHP:

<?
$j = 100000;

/* elegant en traag: */

class Foo {
    
    private $bar;
        
    public function setBar($bar) {
        $this->bar = $bar;
    }
    
    public function getBar() {
        return $this->bar;
    }
}
$foo = new Foo();
$foo->setBar("bar");

$s = microtime(true);
for($i = 0; $i < $j; $i++) {
    $bar = $foo->getBar();
}
$e = microtime(true);
echo $e-$s."<br>";

/* lelijk en snel: */

$foo = new stdClass;
$foo->bar = "bar";

$s = microtime(true);
for($i = 0; $i < $j; $i++) {
    $bar = $foo->bar;
}
$e = microtime(true);

$e = microtime(true);
echo $e-$s."<br>";
?>