[PHP] classes en objects in php waarom?

[Verwijderd]

goede avond,

ik zit al een poosje vol aandacht de info op tweakers te lezen mbt php en classes en objecten.
Ook op de rest van het web zit ik vanalles te lezen.
Hoe het werkt (technisch) is me redelijk duidelijk en het nut van een dbClass of fileuploadClass is me ook wel duidelijk.

Maar wat ik niet begrijp is wat nu het nut is van een Object in een webapplicatie.
Stel dat ik een website maak met een auto-overzicht.
Dan heb ik dus grofweg de volgende opties:
- overzichtslijst van meerdere auto's
- detailpagina van auto
- auto toevoegen
- auto editen
- auto deleten

Nu kan ik uiteraard een class auto gaan maken met diverse methods maar hoe pas ik dit dan toe?
Bij het toevoegen van een nieuwe auto bijv. stop ik de gegevens vanuit een formuliertje rechtstreeks in de database. Moet ik nu voor de INSERT-query een object auto gaan aanmaken met de gegevens uit het formuliertje? Of moet ik de gehele INSERT-query dus dan als method in de class auto gaan zetten?
En wat is dan het voordeel van zo'n class?

Ik bedoel, bij het openen van een andere pagina op mijn website is mijn object ook weer foetsie toch?

misschien een enorme noob-vraag hoor, maar ik zie het niet helemaal

[ Voor 4% gewijzigd door Verwijderd op 02-07-2007 19:45 ]

[Y0ur1]

Je kunt objecten serializeren en dan in je sessie opslaan. Maar bij een taal als PHP zou ik OO inzetten waar het handig en nuttig is, dus niet als doel ansich. Je kunt een hele mooie architectuur maken met PHP, database abstractie´s, domein klassen etc etc maar de vraag is of je dat wil doen bij kleinere projecten.

[user109731]

Verwijderd schreef op maandag 02 juli 2007 @ 19:43:
Nu kan ik uiteraard een class auto gaan maken met diverse methods maar hoe pas ik dit dan toe?
Bij het toevoegen van een nieuwe auto bijv. stop ik de gegevens vanuit een formuliertje rechtstreeks in de database. Moet ik nu voor de INSERT-query een object auto gaan aanmaken met de gegevens uit het formuliertje?

Je kunt bijvoorbeeld een class Car maken met een (static) functie die een nieuwe car terug geeft, op basis van de gegeven input... Een andere (niet-static) functie is dan bijvoorbeeld save() waarmee je 'm in de database kunt opslaan

Of moet ik de gehele INSERT-query dus dan als method in de class auto gaan zetten?
En wat is dan het voordeel van zo'n class?

Over de voordelen van OO is genoeg te vinden, maar ondere andere: Hergebruik: door je classes generiek op te zetten kun je ze later weer gebruiken. Bescherming van je data: door je members private/protected te maken kunnen die niet direct gewijzigd worden, enkel via functies die jouw class aanbied. Bovendien zet je alle relevante functies voor een bepaald object in 1 class, wat je code veel overzichtelijker maakt.
Ik maak zelf altijd een aantal static functies: getCarById($id), getAllCars(), etc. Deze geven een car-object of een array ervan terug. Hiervoor kunnen ze dan weer car::fromRow($row) ofzo gebruiken die een 'rij' in de database omzet naar een car object.

Ik bedoel, bij het openen van een andere pagina op mijn website is mijn object ook weer foetsie toch?

Je kunt ze in een sessie opslaan, maar vaak bouw je ze bij elke request op ja

[Jimbolino]

In java is het verplicht om objecten te gebruiken, maar in PHP is het een keuze.
Als je een simpel hello world scriptje schrijft, is het natuurlijk onzinnig om objecten te gaan gebruiken.

Hoe groter (en complexer) het systeem wordt, hoe meer de voordelen van OO naar voren komen.
OO is onder andere bedacht om grote systemen overzichtelijk te maken voor de programmeurs.

Maar omdat in PHP objecten alleen voor een paar ms bestaan (tijdens een request), moet je een truukje verzinnen om ze op te slaan. Serializen is daarvoor het makkelijkste. Ge-serializde objecten kun je ook meteen in de database zetten. (pas wel op dat als je daarna de methodes van je object aanpast, je niet veel meer aan je serialized object hebt)

[storeman]

Object georienteerd bezig zijn heeft vooral betrekking op de complexiteit beheersen. Overzicht bewaren gaat veel makkelijker en is de voornaamste reden om met objecten te werken. Een andere reden is overerving. Wanneer je dit goed opzet kun je jezelf veel werk besparen. Ook met de jaren kun je eenvoudiger veranderingen en optimalisaties doorvoeren.

Het idee dat jij opnoemt met de overzichten en detailpagina's kan zeer goed gerealiseerd worden in een systeem met objecten.
In eerste instantie zul je dit in statisch html gaan ontwikkelen, maar op den duur zul je wellicht met AJAX willen gaan werken. In een object zul je dan een functie toe moeten voegen die de data parst die geschikt is voor AJAX, de initialisatie bestaat al in het bestaande object. Om maar wat te noemen.

[SchizoDuckie]

De reden om met objecten te werken is erg simpel: Hergebruik

Zodra je vaker websites bouwt merk je dat je telkens jezelf aan't herhalen bent. JanDM schrijft bijvoorbeeld dat hij altijd getObjectByID en getAllObjects functies aanmaakt.

Ikzelf heb dit inmiddels zover ge-abstaheerd dat er een standaard 'dbObject' object is, waarvan al m'n objecten extenden die aan een database tabel zitten.

Lees bijvoorbeeld uit m'n sig eens het stukje over m'n O/R mapper en de examples erbij en je het zal je veel duidelijker worden

[Verwijderd]

Thanks voor het commentaar,

't is niet zo dat ik OO als doel heb maar ik heb het idee dat, om een stapje verder te komen en toch eens wat efficienter te werken, het wel enorm handig is om me maar eens te wagen aan classes en objecten.
En dat zal in het begin eerder overkill zijn wat me 4x zoveel werk kost dan een fetch_array'tje + een echo'tje zeg maar.
Dat kost me wel wat piekerwerk maar dat vind ik ook wel weer leuk.

Maar is bij het toepassen van classes gebruikelijk om een directe relatie tussen db-Tabel (auto) en class (auto) te hebben met bijv. als method getCarByID of is het ook gebruikelijk om dan getCarAndDriverById te gebruiken waarbij je dan in je class Car toch via een LEFT JOIN data oproept die eigenlijk bij class Driver (of Person) hoort? (mm ik hoop dat dit duidelijk is?)

En is een overzicht van auto's een aparte class (AutoList) of een gereturnde array met meerdere auto's vanuit je class (Auto)?

Dit zijn vragen die een beetje blijven hangen en waarop ik niet het antwoord heb gevonden (of wellicht verkeerd voor heb gezocht) het P.O.R.K-verhaal is me al wel wat helderder dus dat ga ik maar eens verder bekijken.

Ik zoek op de een of andere manier een beetje naar de best practice maar dat vind ik waarschijnlijk door er zelf mee aan de slag te gaan.

[storeman]

Voor het ontwerpen van je classes bestaat er niet één goede manier. Er zijn vele manieren en er is niet een perfecte manier. Een goede abstractie hanteren is één, maar er is meer nodig voor fatsoenlijk OO programmeren. Een list hoeft niet perse een eigen class te hebben, lijkt me een beetje overkill zelfs, om een class voorraad te hanteren zou mij logischer lijken, hierin een functie met parseList of een functie waarmee je de data kan verkrijgen waarmee je vervolgens een list parsed.

Wat betreft de relatie tussen de class en de db is het afhankelijk van het niveau van je class. Op het bovenste niveau is dit zeker niet gek, maar voor een laag dieper is dit waarschijnlijk moeilijker te verantwoorden (niet dat het slecht is, maar er moet een goede reden voor zijn).

Nog een opmerking met betrekking tot 'veel werk', het mooie van OO is natuurlijk dat er ook al veel verschillende classes gebouwd zijn, deze zijn natuurlijk redelijk eenvoudig te integreren in een nog op te zetten systeem. Ga dus niet zelf het wiel altijd opnieuw uitvinden.

[Jimbolino]

objecten kun je het beste modeleren naar de werkelijkheid.
daarom is het logisch dat je een object Auto en een object Persoon maakt.

Hoe je dan de relatie tussen die 2 legt is afhankelijk van wat voor systeem je maakt.
Wil je dat elke Auto maar één eigenaar heeft, maak je gewoon een atribuut Eigenaar (van het type Persoon) in het Auto object.

Je zou dan iets krijgen als:
$car->eigenaar->getInfo();

Als je de relatie omdraait: één eigenaar heeft 1 of meerdere auto's. Dan krijg je een eigenaar object met daarin een array met auto objecten:
$eigenaar->getAutoByID(1)->getInfo();

Kortom, genoeg mogelijkheden, aan jou om te bepalen welke het makkelijkste/beste is voor jouw doel.