[php] Nut van objectgeoriënteerd programmeren

[Verwijderd]

Ik maak nu al een aantal jaren websites en dergelijke met php, de laatste tijd heb ik mij verdiept in Object Orienteerd programmeren omdat vele mensen mij dit aanraadde. Echter heb ik mijn twijfels nu na een aantal grotere projecten of het wel zo verstandig is om object georienteerd te programmeren.

Daarom som ik hier een aantal voordelen op:
+ Overzichtelijk
+ Gemakkelijk uitbreidbaar
+ Onderdelen zijn gemakkelijk afzonderlijk aan te passen
+ Mooie scheiding tussen Gui en Backend

Maar de negatieve:
- Veel bestanden includen
- Veel overbodige functies aanwezig
- Heel object inladen (Alle attributen uit DB halen en setten als je maar 1 attribuut nodig hebt)
- ...

Ik ben ervan overtuigd dat OOP zeker zonder twijfel gebruikt moet worden in Java en dergelijke maar in Php heb ik er mijn twijfels over... Om de simpele reden dat bij elke request zoveel includes gedaan worden en dat er zoveel overbodige dingen gedaan worden die na die request weer weg zijn.

Ik heb een Gui die veel gebruikt maakt van Ajax requests en dus telkemale maar zeer kleine dingen moet aanpassen of ophalen. Maar soms 5-6 Object en Managers moet ophalen.

Is het dan zo verstandig op OOP te gebruiken of is dit gewoon niet snel genoeg en geheugen vretend voor een webapplicatie of website?

[djluc]

Als het gaat om applicaties die een enorme load hebben kan je gelijk hebben maar voor de andere 99,999 procent geldt dat onderhoud aan software duurder is dan hardware en je dus voor de meest overzichtelijke oplossing moet kiezen wat mij betreft.

[Boudewijn]

Wat is het alternatief als je een groter project wil doen? Functioneel programmeren? Gewoon imperatief programmeren met functies en structs?

Overbodige functies: Tsja, dan heb je verkeerd design.
Bestanden includen: wat is er mis mee?
Objecten inladen:Computer resources zijn veel goedkoper dan human resources . Je kunt beter een paar kb geheugen meer gebruiken dan een uurtje meer programmeren.

AJAX is mischien niet het meest goede vergelijkingsmateriaal: heb je ooit eens een gewoon programma (al dan niet met een GUI) geschreven , en vergeleken met de door jou voorgestelde methodes?


Qua PHP : Tsja, is PHP wel ooit compleet bedoeld om OOP te gebruiken? Afaik is dat niet direct het geval.

[Verwijderd]

Zal een voorbeeldje geven wanneer ik toch begin te twijfelen.
Ik heb bv. een klantnaam nodig van een verkocht product.

Normaal doe je 1 query en echo je het result.

Nu met OOP include ik een database class, een manager, het object.
Vervolgens wordt het object geinstantieerd en haalt hij alle attributen uit de DB op.
vervolgens haal je met een getter de klantnaam en echo je hem.

Opzich niet veel werk voor te programmeren eenmaal die manager en object en dergelijke gemaakt is maar lijkt me toch veel geheugenvretender te zijn als een 1 simpele query...

[Cartman!]

Daarvoor heb je natuurlijk caching Ik moet er niet aan denken een complexere site zonder OOP te maken. Moet je de boel eens refactoren en dan ben je de zak, nee dankje

edit:

Vervolgens wordt het object geinstantieerd en haalt hij alle attributen uit de DB op.

of je SELECT * gebruikt staat natuurlijk los van OOP of procedureel.

[ Voor 33% gewijzigd door Cartman! op 01-05-2010 21:47 ]

[Boudewijn]

Ja dus? Wat kost dat aan geheugen in euros? En aan onderhoud?
En is dit niet inherent aan je ORM en niet aan PHP?

[YopY]

Verwijderd schreef op zaterdag 01 mei 2010 @ 21:36:
Zal een voorbeeldje geven wanneer ik toch begin te twijfelen.
Ik heb bv. een klantnaam nodig van een verkocht product.

Normaal doe je 1 query en echo je het result.

Nu met OOP include ik een database class, een manager, het object.
Vervolgens wordt het object geinstantieerd en haalt hij alle attributen uit de DB op.
vervolgens haal je met een getter de klantnaam en echo je hem.

Opzich niet veel werk voor te programmeren eenmaal die manager en object en dergelijke gemaakt is maar lijkt me toch veel geheugenvretender te zijn als een 1 simpele query...

Volgens mij kijk je te beperkt. Waar wordt er nog meer iets gedaan met je klanten? Aangezien 'klantnaam' slechts een eigenschap is van een klant. Ik neem aan dat, naast ergens een klantnaam weergeven, er ook volledige logica is voor het beheren van klanten, bestellingen, etcetera, niet?

Wat doe je in dat geval liever: Een query (+ alles wat daarbij hoort) maken en schrijven voor elk punt waar je iets met klanten doet, of één generiek herbruikbaar punt waar je alles met een klant kunt doen?

En daar komt ook nog bij: Wordt die query wel elke keer uitgevoerd? Of komt de klantnaam voor in een gedeeltelijk template die zegt "Welkom, X" dat gewoon per gebruiker gecached wordt?

Wel OOP of niet is vaak een kosten / baten punt. Bij goede toepassing zul je, inderdaad, minder performance hebben (alhoewel dat met goed ontwep van zowel je applicatie als de caching die je bij grote websites zult moeten gebruiken te beperken is), maar daartegenover staat dat je minder 'copy-paste' code zult (of kunt) schrijven, dat je veel beter aannames kunt doen hoe iets werkt (als je in een team werkt), dat het systeem veel makkelijker aan te passen en uitbreidbaar is (door strak georganiseerde en herbruikbare code dat in nette, niet al te grote brokjes opgedeeld is), etcetera.

Natuurlijk is dat ook te bereiken met 'klassiek' programmeren, maar... nouja, d'r zal vast wel een reden zijn waarom OOP veel meer gebruikt wordt dan iteratief bij Alle Grote Bedrijven.

Een uurtje een ontwikkelaar inhuren is vaak duurder dan een nieuwe processor of meer geheugen in een server te proppen. Dus, als je goede, nette en herbruikbare code hebt die niet zo vlot draait, zal het voor de klant uiteindelijk goedkoper zijn - en ook voor iedereen die met de code moet werken.

[Kwastie]

Om met PHP (OOP) te programmeren is het bijna noodzakelijk om met een framework te gaan werken dat gebaseerd is op MVC. (Model-View-Controller). Applicaties gebaseerd op MVC over het algemeen een stuk beter te onderhouden, omdat de code gescheiden is.

Zelf ben ik fan van het Symfony framework, omdat dit veel 'standaard' stukken code, zoals bijvoorbeeld het maken van formulier, data ophalen uit de database al in het framework zit scheelt het erg veel tijd (dus geld) en kun je dus meer maken in een kortere tijd, maar dit is bij de meeste (grote) frameworks zo.

leesvoer: Wikipedia: Model-view-controller-model

[ Voor 5% gewijzigd door Kwastie op 01-05-2010 22:41 ]

[Verwijderd]

Het verschil zit hem helemaal niet tussen OO of Procedureel programmeren maar tussen gestructureerd of ongestructureerd werken. Tenminste, dat is wat de topic starter eigenlijk suggereert. Want of je nu objecten hergebruikt of procedures, je zult moeten "includen" en algemenere objecten/functies schrijven.

Dus ja, je kunt op elke pagina het wiel opnieuw uitvinden en hele pagina specifieke (snelle) logica schrijven en dat gaat ten koste van de herbruikbaarheid/onderhoudbaarheid. Het is niets meer dan keuze.

Dus tijd voor een topic titel wijziging: "nut van gestructureerd programmeren"

[Gamebuster]

"Heel object inladen (Alle attributen uit DB halen en setten als je maar 1 attribuut nodig hebt)"

Dat is niet het geval. Ik programmeer dan wel OOP in Java (geen PHP OOP ervaring, wel PHP ervaring), maar je kan bijv. een Interface aanmaken en daarin de functies defineren, bijv.:

code:

interface Topic {
  function getPostCount();
  function getPost($offset);
  function getPosts($offset, $count);
  function getTitle();
  function getAuthor();
}

Vervolgens maak je meerdere implementaties van dat interface. Zo kan je 1 implementatie schrijven die alle data los ophaalt; wanneer de post-count wordt gevraagd wordt er een query gestart om het aantal posts te tellen. Wanneer er een post geladen wordt wordt er 1 post geladen; enz. Deze variant noem ik zelf altijd Unbuffered[interface], in dit geval: UnbufferedTopic.

Een andere implementatie van datzelfde interface kan juist alles eerst eenmalig laden en bewaren in een variable of alleen de result set (met references naar de data) bewaren in een variable. Zodra je een methode aanroept wordt de data gewoon uit de variable gehaald. Deze variant zou in dit geval bij mij BufferedTopic heten.

Verder kan je nog meerdere implementaties van dat interface schrijven; dat is het mooie van OOP.

[Boudewijn]

En wat te denken van maintenance voordelen door inheritance, maar ook polymorphism en encapsulation?
Dat kun je niet makkelijk namaken zonder OOP.

[H!GHGuY]

Verwijderd schreef op zaterdag 01 mei 2010 @ 21:36:
Normaal doe je 1 query en echo je het result.

Nu met OOP include ik een database class, een manager, het object.
Vervolgens wordt het object geinstantieerd en haalt hij alle attributen uit de DB op.
vervolgens haal je met een getter de klantnaam en echo je hem.

Plak eens even op alle operaties die je hier noemt een tijdsduur. Dan kom je er al gauw achter dat de langste operatie de DB-query is. Of je nu 1, 2, 10 of 30 attributen uit een databank haalt, maakt meestal weinig uit.
Bovendien valt dit allemaal te parallelliseren.
Naast de database-operaties die waarschijnlijk in de grote-ordes van milliseconden duren, zijn de andere operaties in grote-ordes van micro-secondes echt peanuts.

Daarboven zijn hardwarekosten bovendien ook peanuts tov developerkosten.