[PHP] Aantal vragen betreffende OOP in PHP

[daboemann]

Hallo PHP programmeurs,

Ik werk sinds ik op de middelbare school (2 jaar geleden) informatie heb gevolgd met PHP en dit bevalt me goed. Echter zit ik nu op een ICT opleiding waar Object Oriented Programming en efficient programmeren helemaal hot is.
Dit heeft bij mij enkele vragen opgeroepen over mijn PHP programmeren. Ik heb geleerd PHP te programmeren op waarschijnlijk de meest simpele en lelijkste manier en daar ben ik nu verandering in aan het brengen. Na al veel op internet gelezen te hebben zijn er een aantal vragen waar ik toch niet helemaal uit kom.

Een van die vragen betreft het OOP zelf, oftewel verschillende klassen maken waar je vervolgens weer objecten van kunt maken die dan vanalles doen. Mijn vraag: wanneer gebruik je dit nou in PHP? Op de opleiding leer je OO JAVA te programmeren en aangezien dit allemaal stand-alone programmatjes zijn zonder een database ofzo eraan vast is het handig om het in klassen te programeren. Ook vind ik (persoonlijke mening dus) het logisch om zo te programeren. Maar als ik dan ga kijken naar PHP & MySQL waar je met database connecties werkt en het geen 'programma' is dat een user meerdere keren achter elkaar uit kan voeren (telkens is er een compleet nieuwe sessie), roept het bij mij de vraag op wanneer je dan klasses zou gebruiken.
Ik ben nu op het punt dat ik voor alles functies opstel om vervolgens middels require in de pagina's te laden waar ze nodig zijn(dit omdat dit toch wel handig is als je aanpassingen moet maken + om cohesie van code te voorkomen.. iets wat ik imho al veel eerder had moeten doen). Vaak kan ik het met die functies alleen al af en kan ik me niet voorstellen dat je ooit klassen nodig zult hebben in PHP. Is dat dan OO genoeg? Of denk ik verkeerd?

Als iemand mij een voorbeeld zou kunnen geven van een geval waar je overduidelijk klassen nodig hebt wordt het hopelijk iets duidelijker.

Stel je wilt een forum maken waar een gebruiker kan inloggen en berichtjes kan plaatsen (heb ik eens voor informatie geprogrammeerd, werkte perfect, was ook een 10, maar als ik het nu bekijk had het wel netter gekunt), zou je dan in zo'n geval klassen gebruiken en wat voor dan? Want op zich kun je een klasse maken van 'topic' en dan een klasse 'bericht' en dan meerdere berichten 'objecten' koppelen aan één 'topic' object. Maar dit kan je dan toch net zo goed doen door via mysql te kijken welke childID's overeenkomen met het parentID en dan vervolgens de info ervan laden in een lus (met if-statements voor bijvoorbeeld het wijzigen van je eigen berichten). Immers als je naar de wijzig_bericht pagina gaat (als het een andere pagina is), moet je toch weer alle info van dat bericht opnieuw ophalen uit de database toch? want je zit in een andere pagina en tenzij je de gegevens hebt opgeslagen in de pagina waarin jouw huidige ding geinclude is, ben je ze best wel kwijt ($_SESSIONS,$_POST en $_GET zijn dan weer uitzonderingen). Of is het zo dat je die op een 'hoger niveau' opslaat in variabelen en dan vervolgens honderden object berichten in je geheugen hebt staan?

Ik geloof dat ik een beetje de weg begin kwijt te raken. Misschien is het ook wel zo dat je niet alles met klassen kunt / moet programeren maar alleen klassen die bijvoorbeeld een bepaald stukje output genereren / formatten / die je dus telkens opnieuw kunt gebruiken moet maken en de rest 'normaal' moet programeren ?


Dan nog een andere vraag ik lees af en toe van 'ik gebruik in mijn code vaak een abstractie laag om output en business logica gescheiden te houden'. Nou weet ik van JAVA dat het handig kan zijn om die twee gescheiden te houden zodat je het een aan kunt passen zonder dat je de werking van de andere beïnvloed en je dus makkelijk wijzigingen door kunt voeren. Maar als ik kijk naar mijn manier van PHP programmeren dan zit ik toch vaak met echo's te werken in functies e.d. Zou je dan om zo'n 'abstractie laag' te creeëren je functies om moeten gooien zodat ze altijd iets returnen en aan de hand van wat ze returnen laat je iets aan de gebruiker zien middels een echo? Of is het iets gecompliceerder dan dat?

Ik hoop dat iemand hier mij kan verlichten zodat ik toch eens code kan maken die ook door andere aan te passen is, aangezien dit wel zo handig is.

Met vriendelijke groet en alvast bedankt,

Martijn

[RobIII]

Hoewel je topic aardig op PHP gemikt is lijkt me dit meer iets voor SEA gezien je algemene(re) vraag gaat over het (on)nut van OOP.

PRG >> SEA

[ Voor 26% gewijzigd door RobIII op 10-02-2009 19:15 ]

[Verwijderd]

Nouja, het nut van OOP, in het speciale geval nl. webbased applicaties in mijn ogen.

Wanneer je een desktop client gebruikt blijven de objecten bestaan zoalng de applicatie draait, en via serializen eventueel nog langer.

Op een webapplicatie moet alles in mijn ogen bij elk request helemaal opnieuw worden opgebouwd. Ik vraag me dus ook een beetje af wat precies de meerwaarde is voor het toepassen van OOP met PHP.

[Victor]

De stateless aard van een webapplicatie doet niets af aan de voordelen van OO. Als je (nog) niet thuis bent in OO, maar je hebt wel ervaring met het maken van datamodellen, vraag je dan dit af: waarom neem je de moeite om een zuiver, genormaliseerd model te maken van je probleemdomein? Als je die vraag voor jezelf kunt beantwoorden, stel jezelf dan de volgende vraag: waarom maak ik wel een relationeel model voor mijn dataopslag, maar niet voor mijn code (het objectmodel)?

[Kalentum]

Een voorbeeld: een systeem waarin projecten en klanten zitten. Deze hebben uiteraard allemaal verschillende kenmerken. Maar ook gemeenschappelijke kenmerken, bv een 'eigenaar' (iemand die verantwoordelijk is voor dat brokje informatie). Een klant class ziet er dan zo uit:

PHP:

class Customer {
  public function getOwner {
    return $this->owner;
  }
  public function getName() {
    return $this->name;
  }
}

en project:

PHP:

class Project {
  public function getOwner {
    return $this->owner;
  }
  public function getProjectCode() {
    return $this->code;
  }
}

Dan is het handig om een class ApplicationObject te hebben die de algemene kenmerken die voor alle objecten gelden heeft:

PHP:

class ApplicationObject {
  public function getOwner {
    return $this->owner;
  }
}

en class Project en class Customer nemen dan die eigenschappen over (inheritance):

PHP:

class Project extends ApplicationObject {
  public function getProjectCode() {
    return $this->code;
  }
}

class Customer extends ApplicationObject {
  public function getName() {
    return $this->name;
  }
}

Dit als simpel voorbeeld van waarom OOP binnen PHP toch handig kan zijn. Voor simpele toepassingen (een read-only website bv) kan procedureel werken prima gaan maar voor complexere systemen leidt dat al snel tot problemen op het gebied van onderhoud.

Verder is heb je bij procedureel programmeren het probleem dat al je functies unieke namen moeten hebben. BV in bovenstaand voorbeeld zou je een file 'project.php' kunnen hebben met een functie 'getName()' en een file 'customer.php' met ook een functie 'getName()'. Als je nu in 1 pagina zowel een projectnaam als een klantnaam wil opvragen dan doe je twee includes. Dan heb je dus twee functies 'getName()' en dat gaat niet. Dan moet je die functienamen wijzigen in 'project_getName()' en 'customer_getName()'. Eigenlijk ben je dan al bezig een soort van OOP te maken binnen een procedureel paradigma. En dat kan ook wel (ook binnen Java kun je zo werken) maar het wordt al snel een rommeltje.

Voor wat betreft je opmerking over het scheiden van logica en output: niet altijd is HTML gewenst. Het komt regelmatig voor dat je dezelfde informatie als PDF moet presenteren, of naar Excel, of als XML of JSON. Als je functie 'getName()' zowel html code als businesslogica bevat (bv het combineren van een voornaam met een achternaam) dan kom je al snel in de problemen en mag je elke functie gaan herschrijven.

Uiteraard is de werkelijkheid nog complexer. Kijk voor de grap eens naar de reference van Zend Framework of 1 van de tientallen andere PHP frameworks (vrijwel allemaal object georienteerd). Hoe complexer de situatie, hoe handiger OOP wordt.

Waarmee niet gezegd is dat het een noodzaak is . Als je een website hebt met drie menu-items kan procedureel werken toch prima gaan.

[frickY]

Zoals je het nu omschrijft klinkt het alsof je nog steeds procedureel werkt, maar je functies nest in een classe. Dat is niet OO, dat is procedureel met functies genest in classes

Kijk eens of je hier wat wijzer van wordt.