[php] Het nut van OO classes

[mrFoce]

Kan iemand mij mischien in duidelijk nederlands uitleggen wat nou precies het echte voordeel is van in 'classes' programmeren ( php ). Ik zelf werk bijv. alleen met functies en dat werkt gewoon perfect.

Ik heb verscheidende documenten doorgelezen en zie door de bomen het bos niet meer.

Heb o.a hier gekeken : http://www.php.net/manual/en/language.oop5.php , http://www.php-editors.com/articles/simple_php_classes.php , http://php.resourceindex....ion/Class_Design_and_OOP/

Maar ik blijf het nut ervan niet zien ( ik denk zelf dat ik iets over het hoofd zie ), daarvoor 'vraag' ikhet hier ff.

[chem]

[search=Het nut van OO classes php] ?

[mrFoce]

daar kan ik niet iets nuttigs vinden. Sommige mensen 'posten' wel voorbeelden maar zoals ik al zei heb ik zoveel gezien dat ik door de bomen het bos niet meer zie. En nog steeds het echte nut er niet van inzie.

[Obliterator]

Voor een simpele website is het nut ook vaak ver te zoeken. Maar om code herbruikbaar te maken is het wel erg handig. Lees bovenstaande links maar eens.
Of kijk bijv. eens naar http://www.hotscripts.com/Detailed/21237.html

[.oisyn]

OO is wel nuttig, OO in PHP echter niet

[Koeniepoenie]

.oisyn schreef op 01 november 2004 @ 16:22:
OO is wel nuttig, OO in PHP echter niet

OO in PHP vind ik wel nuttig hoor, hoewel de OO functies in PHP 4 niet erg uitgebreid zijn, kun je wel mooi classes hergebruiken etc.

Ook vind ik dat je code een stuk gestructureerder is.

[Rataplan]

Overerving is maar 1 van de nuttige eigenschappen van OO, maar wel de belangrijkste imo. Misschien dat een voorbeeldje helpt?

code:

class Human{
  function RespondToViolence(){
    Run_Like_Hell();
  }
}

class Stallone extends Human{
  function RespondToViolence(){
    Maim_And_Kill();
  }
}

...en nou mag je altijd RespondToViolence() gebruiken. Je ziet vanzelf met welk type Human je te maken hebt

offtopic:
.oisyn: zoek jij ruzie of zo?

[ Voor 2% gewijzigd door Rataplan op 01-11-2004 16:29 . Reden: f*cking republicans :D ]

[Erkens]

.oisyn schreef op 01 november 2004 @ 16:22:
OO is wel nuttig, OO in PHP echter niet

kan je dat ook onderbouwen?

[Wolfboy]

KoenieMan schreef op 01 november 2004 @ 16:23:
[...]

OO in PHP vind ik wel nuttig hoor, hoewel de OO functies in PHP 4 niet erg uitgebreid zijn, kun je wel mooi classes hergebruiken etc.

Ook vind ik dat je code een stuk gestructureerder is.

Je code kan ook best gestructureerd zijn zonder OO hoor. Ik ben het iig met .oisyn eens, in php4 heb je er iig niet veel aan (php5 heb ik nog niet geprobeerd)

[Skaah]

Extenden... zie dit voorbeeld.

[.oisyn]

Erkens schreef op 01 november 2004 @ 16:26:
[...]

kan je dat ook onderbouwen?

1. UTFS
2. Geen encapsulatie, geen polymorphisme. Ergo: geen OO

[Zoijar]

Rataplan schreef op 01 november 2004 @ 16:25:
Overerving is maar 1 van de nuttige eigenschappen van OO, maar wel de belangrijkste imo. Misschien dat een voorbeeldje helpt?

Inheritance is overrated Wordt veel te vaak incorrect gebruikt, alleen maar omdat mensen denken dat het dan *drums* OO is...terwijl veelvuldig oncorrect inheritance gebruiken eerder 0_o is

[Erkens]

.oisyn schreef op 01 november 2004 @ 16:36:
[...]


1. UTFS

en dat voor een modje

2. Geen encapsulatie, geen polymorphisme. Ergo: geen OO

en dan heeft het uiteraard geen nut meer nee

[.oisyn]

Hoe kan iets nut hebben terwijl het niet bestaat

Was trouwens nog een puntje vergeten, namelijk de reference crap die in php5 eindelijk gefixed is. Je zit al gauw objecten te kopiëren als je niet voorzichtig bent.
En het is natuurlijk gewoon niet type-safe.

Daarnaast, OOP kan in bijna elke (imperatieve) taal. Of je het ook wilt als de taal je er geen (goede) features voor biedt is een tweede.

[ Voor 82% gewijzigd door .oisyn op 01-11-2004 16:45 ]

[Erkens]

.oisyn schreef op 01 november 2004 @ 16:40:
Hoe kan iets nut hebben terwijl het niet bestaat

php4 heeft idd niet alle eigenschappen om volledig OO te zijn, maar daarom zijn de mogelijkheden die je hebt toch niet nutteloos
Overigens kan je wel (beperkt) gebruik maken van polymorphisme in php4

[Rataplan]

.oisyn schreef op 01 november 2004 @ 16:36:
1. UTFS

"Nutteloos geblaat"

2. Geen encapsulatie, geen polymorphisme. Ergo: geen OO

Kruimeltjes zijn ook cake. En verder was de vraag waarom wat er wél aan OO-eigenschappen in PHP zit, niet nuttig is. Da's je stelling, voor het geval je dat vergeten was.

.oisyn schreef op 01 november 2004 @ 16:40:
Was trouwens nog een puntje vergeten, namelijk de reference crap die in php5 eindelijk gefixed is. Je zit al gauw objecten te kopiëren als je niet voorzichtig bent.
En het is natuurlijk gewoon niet type-safe.

Oh, dus in php5 zit wel OO? Maar php5 is geen php?

[ Voor 32% gewijzigd door Rataplan op 01-11-2004 16:48 ]

[JeRa]

.oisyn schreef op 01 november 2004 @ 16:40:
Hoe kan iets nut hebben terwijl het niet bestaat

Leuk geflame.

In PHP is het erg handig om meerdere databases aan te sturen d.m.v. DB-classes die elk hun eigen implementatie hebben maar in het main programma dezelfde aanroep (e.g. $DB->Connect()).

Verder zijn er veel andere voorbeelden te verzinnen; ik noem artikels (winkelwagen), modules voor communityscripts of informatieprogramma's; sinds PHP5 is er veel meer qua OO mogelijk en komt het qua functionaliteit steeds meer in de buurt van classes in C++ (hoewel strong typing nog steeds m'n voorkeur heeft ipv type hinting zoals die in PHP voorkomt).

[Zoijar]

.oisyn schreef op 01 november 2004 @ 16:40:
Hoe kan iets nut hebben terwijl het niet bestaat

Geen bugs is best nuttig

[Sybr_E-N]

Erkens schreef op 01 november 2004 @ 16:43:
[...]

php4 heeft idd niet alle eigenschappen om volledig OO te zijn, maar daarom zijn de mogelijkheden die je hebt toch niet nutteloos
Overigens kan je wel (beperkt) gebruik maken van polymorphisme in php4

In PHP5 is het inmiddels al aardig uitgebreid, maar het is nog niet 100% OO. Het komt wel een aardig eind in de richting.

Ik weet niet of gideon82 ook ervaring heeft met OO talen als Java of C++?

[bat266]

De mods moeten tog t goede voorbeeld geven ofnie
ontopic:
Ik gebruik redelijk veel classes in php omdat ik dan alles kan hergebruiken en eventueel onderling uitwisselen. Dat in php het nog geen volwassen versie is ok, maar ik vind het voordeel dat alles duidelijk gestructureerd te lezen is het aller belangrijkste zeker als je later iets wilt wijzigen.

[Rataplan]

Zoijar schreef op 01 november 2004 @ 16:37:
[...]

Inheritance is overrated Wordt veel te vaak incorrect gebruikt, alleen maar omdat mensen denken dat het dan *drums* OO is...terwijl veelvuldig oncorrect inheritance gebruiken eerder 0_o is

Inheritance is helemaal niet overrated! Voor de rest ben ik het met je eens, maar foutief gebruik is niet de schuld van de taal, maar (*drums* ) van de progger.

[.oisyn]

JeRa schreef op 01 november 2004 @ 16:45:
[...]

Leuk geflame.

rare definitie van flamen heb jij dan

In PHP is het erg handig om meerdere databases aan te sturen d.m.v. DB-classes die elk hun eigen implementatie hebben maar in het main programma dezelfde aanroep (e.g. $DB->Connect()).

Dat kan met functionpointers ook. Dat is geen OO, dat heet late binding

Verder zijn er veel andere voorbeelden te verzinnen; ik noem artikels (winkelwagen), modules voor communityscripts of informatieprogramma's; sinds PHP5 is er veel meer qua OO mogelijk en komt het qua functionaliteit steeds meer in de buurt van classes in C++ (hoewel strong typing nog steeds m'n voorkeur heeft ipv type hinting zoals die in PHP voorkomt).

OO is een denkwijze, geen manier om je code in te typen. Met losse functies (neem bijvoorbeeld C) kun je ook OO ontwerpen, maar zoals ik al eerder zei, de vraag is of je dat wilt. PHP biedt imho nou niet echt lekkere features om goed OO te kunnen programmeren, de type-safety mist vooral.

Daarnaast leeft een php script nogal kort, waardoor een gedegen OO ontwerp al gauw niet meer nodig is. Je kunt een forum ook wel modelleren zodat het Forum, Topic en Post objecten heeft, je zit echter alleen continu die dingen te spawnen terwijl ze na een aantal statements alweer gedestruct kunnen worden (nog even afgezien van het feit dat php enorm lekt kwa geheugen). Door de korte lifespan loont het niet zo heel erg veel om echt alles in objecten op te gaan zetten.

[Mithrandir]

Ik vind dat PHP beeter namespaces had kunnen implementen dan 'OO'. Meestal worden objecten namelijk niet echt gebruikt, omdat ze toch vaak maar 1 keer worden aangeroepen.

Als er een (goede) manier bestond om niet stateless bezig te blijven in PHP was het al aardig handiger geweest.

[Mithrandir]

.oisyn schreef op 01 november 2004 @ 16:58:
[....]

Zowiezo is het de vraag of het echt handig is om bijvoorbeeld van elk topic of elke post een nieuw object te gaan maken. Iedere nieuwe aanvraag wordt het object aangemaakt en weer gedestroyed, terwijl er in wezen geen functies op hoeven worden aangesproken (foreach($topic as $bla) $bla->print();? geen echt voordeel). Je kunt veel makkelijker, en minder geheugen-consuming, alles opslaan in een array.

Ik mis inderdaad de typesafety in mijn PHP scripts ook. Daardoor heb je zo snel last van bugs en moeilijk controleerbare code

edit:

Eh, oeps, edit .

[ Voor 43% gewijzigd door Mithrandir op 01-11-2004 17:27 ]

[mrFoce]

Ik heb geen ervaring met Java ( dat ga ik over 1,5 week kennis mee maken met een school 'blok van 10 weken. heb daar wel een boek al voor moeten kopen die over UML gaat, en dat is volgens mij het zelfde idee als OO)

Maar als ik alle reacties lees, is mij 'onzekerheid' over OO eigenlijk hetzelfde gebleven. De een ziet er het nut van in en gebruikt het ook en de ander ziet het nu er niet van in.

[ Voor 97% gewijzigd door mrFoce op 01-11-2004 20:28 ]

[mrFoce]

Code. weg ge-edit bedankt voor alle reacties iig

[ Voor 80% gewijzigd door mrFoce op 01-11-2004 20:29 ]

[.oisyn]

Een stuk tekst omzetten naar html is sowieso iets wat niet echt in een object te gooien is: het is gewoon een functie, in de volledige betekenis van het woord. Misschien zou je de configuratie die wordt gebruikt om het om te zetten (voor zover het configureerbaar is, maar denk bijvoorbeeld aan de me tag die voor iedereen anders is) in een object kunnen gooien met een functie om een string om te zetten, maar dan houdt het ook wel op

[Verwijderd]

gideon82 schreef op 01 november 2004 @ 16:13:
Kan iemand mij mischien in duidelijk nederlands uitleggen wat nou precies het echte voordeel is van in 'classes' programmeren ( php ).

Duidelijk engels van een nederlander goed genoeg? the true power of object-oriented programming.

[kieltju]

grappig, ik had het hier van de week nog over. Ik heb ook geen idee wat het is en wat 'ik' ermee kan. Na het lezen van dit tread nog steeds niet.

Ik begrijp dat het voor grote scripts en projecten wel leuk blijkt te zijn maar wat precies dat leuke is... geen idee!

Soms hoor ik mensen erover praten of het de hemel is, en dat terwijl niemand echt goed kan zeggen wat het is en wat 'ik' ermee kan. Dat vind _ik_ ironisch.

[.oisyn]

De vraagstelling was dan ook niet wat OOP (Object Oriented Programming) inhield, maar meer in hoeverre het nuttig was binnen PHP. We kunnen wel in detail gaan treden wat OO nou precies inhoudt, maar dat zou hier enorm offtopic zijn, en daarnaast is het gewoon een vrij basic onderwerp waar heel veel pagina's aan gewijd zijn op het internet

[mrFoce]

Veel pagina's zijn hebben het erover. Overal kom ik mensen tegen die het de hemel inprijzen, en die het 'afkraken' .. Wijzer wordt ik er niet van..

@ kieltje een tutorial die 'makkelijk' uitgelegd is voor de beginner in het nederlands -> http://www.phphulp.nl/php/tutorials/8/214

@ RémyvD : bedankt voor de link, ik ga m morgen doorlezen en kijken of ik daaruit op kan maken hoe nuttig OOP wel niet is in php ( in c++ schijnt het super te zijn )

ff ontopic.

Ik heb verscheidende malen gelezen dat OOP functie zelfs 'iets' trager is dan zonder OOP te werken, dus dat zie ik weer als een 'min' puntje ervoor. Kan iemand dit bevestigen, dan wel van de tafel vegen ?

[Room42]

Maakt het in PHP bijvoorbeeld miliseconden uit als je een boel files include? Classes staan namelijk vaak ik losse files, die je dan include. Dat voor de portabiliteit. Deze moet php dan vervolgens wel allemaal los laden.

[mrFoce]

Room42 schreef op 02 november 2004 @ 01:16:
Maakt het in PHP bijvoorbeeld miliseconden uit als je een boel files include? Classes staan namelijk vaak ik losse files, die je dan include. Dat voor de portabiliteit. Deze moet php dan vervolgens wel allemaal los laden.

erm ? wat bedoel je hiermee te zeggen en is dit ontopic ?

[.oisyn]

Die tutorial gaat nergens over... Wellicht is het handiger om te zoeken naar iets abstracters, een PHP OO tutorial is nou niet echt bepaald de beste plek om mee te beginnen. Mensen die OO willen uitleggen doen dat namelijk niet in PHP omdat het niet taalgebonden is, mensen die het wel mbv PHP uitleggen hebben er meestal niet veel kaas van gegeten (is mijn ervaring) (uitzonderingen daargelaten).

Er zijn op zich wel een aantal nederlandse pagina's te vinden ([google=object georienteerd programmeren], zie bijvoorbeeld dit artikel). Maar ik kan je toch aanraden de Engelse taal gewoon goed onder de knie te krijgen, er is echt zoveel meer informatie beschikbaar in het engels, en als je toch naar een baan zoekt in de development wereld kom je bijna niet om engels heen.

[ Voor 76% gewijzigd door .oisyn op 02-11-2004 01:34 ]

[mrFoce]

.oisyn schreef op 02 november 2004 @ 01:27:
Die tutorial gaat nergens over... Wellicht is het handiger om te zoeken naar iets abstracters, een PHP OO tutorial is nou niet echt bepaald de beste plek om mee te beginnen. Mensen die OO willen uitleggen doen dat namelijk niet in PHP omdat het niet taalgebonden is, mensen die het wel mbv PHP uitleggen hebben er meestal niet veel kaas van gegeten (is mijn ervaring) (uitzonderingen daargelaten).

Er zijn op zich wel een aantal nederlandse pagina's te vinden ([google=object georienteerd programmeren], zie bijvoorbeeld dit artikel). Maar ik kan je toch aanraden de Engelse taal gewoon goed onder de knie te krijgen, er is echt zoveel meer informatie beschikbaar in het engels, en als je toch naar een baan zoekt in de development wereld kom je bijna niet om engels heen.

heb hier ook een mooi boek met UML diagrammen liggen. Zelfde idee

[.oisyn]

gideon82 schreef op 02 november 2004 @ 01:08:
Ik heb verscheidende malen gelezen dat OOP functie zelfs 'iets' trager is dan zonder OOP te werken, dus dat zie ik weer als een 'min' puntje ervoor. Kan iemand dit bevestigen, dan wel van de tafel vegen ?

Wat is trager? En hoe zwaar weegt die zogenaamde traagheid tegenover het veel snellere development proces?

Maar om een antwoord te geven op je vraag: OO zelf is niet trager, het blijven gewoon functie aanroepen met het object als extra parameter. Wat wel zo is is dat je door abstractie geen aannames meer kunt doen over hoe een bepaald iets in elkaar zit, en daarnaast moet je gewoon niet teveel in objecten willen denken: zo zou een string bijvoorbeeld een array van allemaal verschillende Teken objectjes kunnen zijn, maar het is niet handig om ook een Teken object te definieren dat een teken representeert. Als je hier te ver in doorgaat wordt het idd wat trager en heeft het meer geheugen nodig, maar over het algemeen is OO niet trager dan niet-OO, en zeker niet merkbaar trager.

[curry684]

.oisyn: ik vermoed dat gideon82 doelt op de specifieke PHP-implementatie van OOP, en daarvan kan ik me best voorstellen dat deze trager is dan een puur procedurele aanpak omdat er minder overhead op het parsen en bouwen van classes in zit.

Mocht de stelling algemeen bedoeld zijn houdt ie idd geen stand: ik denk hierbij aan de quote van Stroustrup in de inleiding van "The C++ Programming Language" waarbij de C++ compiler op zijn computer kleinere en snellere code bakte van standaard Hello World dan de C compiler op de standaard C versie

[.oisyn]

curry684 schreef op 02 november 2004 @ 01:51:
.oisyn: ik vermoed dat gideon82 doelt op de specifieke PHP-implementatie van OOP, en daarvan kan ik me best voorstellen dat deze trager is dan een puur procedurele aanpak omdat er minder overhead op het parsen en bouwen van classes in zit.

Het parsen van classes kost natuurlijk net zoveel als het parsen van functies, en bovendien is dat geen drol . Bij het aanmaken van classes kan ik me er iets bij voorstellen, maar volgens mij is het ook gewoon wat syntactische suiker om dezelfde hashtable implementatie die ook gebruikt wordt voor arrays.

Mocht de stelling algemeen bedoeld zijn houdt ie idd geen stand: ik denk hierbij aan de quote van Stroustrup in de inleiding van "The C++ Programming Language" waarbij de C++ compiler op zijn computer kleinere en snellere code bakte van standaard Hello World dan de C compiler op de standaard C versie

Nou is Bjarne natuurlijk een beetje bevooroordeeld . Kwa call overhead zit er niet zoveel in, behalve dat vtable calls de instruction pipeline nogal eens om zeep kan helpen (wat zo rond de 15-20 cycles kost op hedendaagse cpu's). De nodige overhead zit voornamelijk in het ontwerp: overdreven puristische OO programma's zullen het over het algemeen slechter doen dan een set functies die alleen doen wat ervan verwacht wordt zonder enige mogelijkheden tot uitbreiding. Maar IRL zal het niet zoveel uitmaken.

[Soultaker]

curry684 schreef op 02 november 2004 @ 01:51:
Mocht de stelling algemeen bedoeld zijn houdt ie idd geen stand: ik denk hierbij aan de quote van Stroustrup in de inleiding van "The C++ Programming Language" waarbij de C++ compiler op zijn computer kleinere en snellere code bakte van standaard Hello World dan de C compiler op de standaard C versie

Dat klinkt ook wel als een enorm betrouwbare en technisch relevante benchmark.

Zelf maak ik in PHP bijna nooit gebruik van OOP. Ik zie een PHP script als een programma wat zo snel mogelijk een HTTP document moet genereren; misschien op basis van wat HTTP invoer. PHP is dus een op templates gebaseerde transformatietaal.

Het nut van OOP komt pas echt kijken als objecten een zekere levensduur hebben in een dynamische omgeving, waarin objecten worden toegevoegd en verwijderen, en relaties gewijzigd worden. In PHP is helemaal geen sprake van die situatie; in de praktijk bestaan alle objecten tegelijk en hun relaties staan al a priori vast. Een PHP script wordt dan ook meestal van onder naar boven uitgevoerd en daarna is het klaar. In zo'n situatie kun je prima procedureel te werk gaan.

Het enige voordeel van OOP in PHP is dat je de staat van objecten kunt koppelen aan hun gedrag. In tutorials kom je ook altijd database-objecten tegen, die bijvoorbeeld hun resultaten bijhouden. Dat is wel fijn, maar fundamentele OOP-principes zoals overerving komen daar helemaal nooit bij kijken. Verder gebruikt PHP zelf een wat klassieker paradigma: bijna alle standaardfuncties retourneren een soort handle (denk aan file en socket functies, database accessibility, image processing, enzovoorts) die ook de staat van een object encapsuleert. Dat is ook een soort object-georienteerd programmeren, maar natuurlijk niet de manier waarop je dat toepast in een 'echte' OOP-gerichte programmeertaal.

[ Voor 13% gewijzigd door Soultaker op 02-11-2004 02:06 ]

[Zoijar]

Onderschat niet hoeveel instructies een moderne cpu kan uitvoeren in de tijd dat je hard disk armpje boven het juiste record in de database staat...Dat zal toch nog wel gemiddeld zo'n 10ms zijn, maar zeg 5ms...dat zijn zo'n 15000 kloktikken tegenwoordig...

[Erkens]

Soultaker schreef op 02 november 2004 @ 02:06:
Zelf maak ik in PHP bijna nooit gebruik van OOP. Ik zie een PHP script als een programma wat zo snel mogelijk een HTTP document moet genereren; misschien op basis van wat HTTP invoer. PHP is dus een op templates gebaseerde transformatietaal.

Waarom zou je door gebruik van OOP niet snel een resultaat kunnen geven, en wat is snel, zelf zie ik liever een kortere development tijd door het hergebruik van code dan dat ik een paar milliseconden win op de uitvoer.

Het nut van OOP komt pas echt kijken als objecten een zekere levensduur hebben in een dynamische omgeving, waarin objecten worden toegevoegd en verwijderen, en relaties gewijzigd worden. In PHP is helemaal geen sprake van die situatie; in de praktijk bestaan alle objecten tegelijk en hun relaties staan al a priori vast. Een PHP script wordt dan ook meestal van onder naar boven uitgevoerd en daarna is het klaar. In zo'n situatie kun je prima procedureel te werk gaan.

Ik heb het zelf nog nooit gedaan (geen behoefte tot gehad) maar afaik kan je objecten gewoon opslaan in een sessie, mits je de definities maar eerst heb geladen voordat je met je sessie variabelen bezig gaat, en dan blijven ze dus langer leven (uiteraard met het nadeel dat ze in principe opnieuw gebouwd wordt, alleen de inhoud is dan hetzelfde als toen je hem erin stopte)

In tutorials kom je ook altijd database-objecten tegen, die bijvoorbeeld hun resultaten bijhouden. Dat is wel fijn, maar fundamentele OOP-principes zoals overerving komen daar helemaal nooit bij kijken.

omdat je dat ook bijna nooit nodig hebt in die gevallen, maar dat is juist wel het nut van OOP in PHP, gezien je argument dat objecten niet lang leven in PHP

[.oisyn]

Erkens schreef op 02 november 2004 @ 08:28:
omdat je dat ook bijna nooit nodig hebt in die gevallen, maar dat is juist wel het nut van OOP in PHP, gezien je argument dat objecten niet lang leven in PHP

Sorry, maar simpelweg wat functies in een class definieren noem ik geen OOP. Als ik het over OOP heb bedoel ik een gedegen ontworpen OO systeem waar encapsulatie, polymorphisme en overerving de boventoon voeren. Wat functies rangschikken binnen een class hoort daar niet echt bij.

Ik ben het dan ook eens met Soultaker, want wat ik al eerder zei, de lifespan van een enkel script is gewoon veel te kort om allerlei relaties tussen objecten te leggen. En over het opslaan ben ik nogal sceptisch; een enkel object zul je wel vrij makkelijk kunnen serializeren, maar wat als dat object nou referenties heeft naar allerlei andere objecten, en die ook weer, en die ook weer, etc.?

[Erkens]

polymorphisme is deels mogelijk met php4, maar dan nog, zoals jij zegt "het rangschikken van functies in een class" is dat niet nuttig?
Ik denk van wel, en wel omdat het een duidelijkere structuur oplevert met als grootste voordeel het makkelijker kunnen verdelen van het programmeer werk. Met losse functies is dat iets lastiger imo, daarnaast los je met het gebruik van classes in php de elende van global variabelen op iets wat anders veel lastiger is
Ik vind het gebruik van de OO mogelijkheden die php4 mij kan bieden enorm nuttig, niemand heeft gezegt dat php4 volledig OO is en niemand wil dat ook beweren volgens mij, vooral de combinatie maakt het extreem nuttig, zonder deze OO mogelijkheden had ik waarschijnlijk sneller gekeken naar een andere taal

[.oisyn]

Erkens schreef op 02 november 2004 @ 10:45:
polymorphisme is deels mogelijk met php4, maar dan nog, zoals jij zegt "het rangschikken van functies in een class" is dat niet nuttig?

Daar heb je andere constructies voor, zoals namespaces, maar dat hebben de lieden van Zend voor het gemak maar even gedropt omdat het bugte (prutsers)

Ik denk van wel, en wel omdat het een duidelijkere structuur oplevert met als grootste voordeel het makkelijker kunnen verdelen van het programmeer werk.

Dat kan zonder gebruik van classes ook wel, bijvoorbeeld door functienamen te prefixen en ze allemaal bij elkaar in dezelfde file te zetten.

daarnaast los je met het gebruik van classes in php de elende van global variabelen op iets wat anders veel lastiger is

Maar uiteindelijk doet het hetzelfde omdat je meestal toch maar 1 object van elk type aan het instantieren bent. Daarnaast moet je er nog altijd $this-> bij typen, dus wat nou het voordeel is tov eerst global maken zie ik niet zo...

Ik vind het gebruik van de OO mogelijkheden die php4 mij kan bieden enorm nuttig, niemand heeft gezegt dat php4 volledig OO is en niemand wil dat ook beweren volgens mij, vooral de combinatie maakt het extreem nuttig, zonder deze OO mogelijkheden had ik waarschijnlijk sneller gekeken naar een andere taal

Mja, misschien ben ik gewoon wat puristischere en denk ik bij OO aan de volledige betekenis van de afkorting, terwijl anderen zoals jij het meer hebben over het gebruik van classes op zich en niet zozeer het zogenaamde OO wat daaruit voort zou kunnen vloeien

[ACM]

Vooropgesteld:
Ik ben het met iedereen eens die claimt dat het "mooier kan dan in php"

.oisyn schreef op 02 november 2004 @ 10:39:
Als ik het over OOP heb bedoel ik een gedegen ontworpen OO systeem waar encapsulatie, polymorphisme en overerving de boventoon voeren. Wat functies rangschikken binnen een class hoort daar niet echt bij.

Dat je die concepten kan gebruiken bij OOP, maakt ze nog niet verplicht natuurlijk. Ook in java kan je alle variabelen public maken, geen getters/setters programmeren etc. Is er dan nog steeds encapsulatie? Ja, imho wel.
Zo ook bij een php-klasse. Zolang je functies op de klasse aanroept, die iets interns doet waar je aanroeper verder geen weet van hoeft te hebben is er imho al (een vorm van) encapsulatie.
Dat dat dan bij Java, C# en anderen veel mooier en stricter uitgevoerd kan worden doet daar niks aan af.

Polymorfisme en overerving worden in php inderdaad wat minder gebruikt, doordat het niet echt typesafe is (php4 iig), is het ook wat minder nodig om zo strict alles volgens polymorfische patronen te programmeren.
Onderstaande codevoorbeelden zullen tenslotte beide werken:

PHP:

// A:
class Test{ function toString() { return "Test"}}
class Test2{ function toString() { return "Test2"}}

// B:
class Object{ function toString() { return "Object"}}
class Test extends Object { function toString() { return "Test"}}
class Test2 extends Object { function toString() { return "Test2"}}

// hulpcode
function useOb($obj) {  echo $obj->toString(); }

// Test:
useObj(new Test());
useObj(new Test2());

Waarom dan de moeite van overerving nemen?

Ik ben het dan ook eens met Soultaker, want wat ik al eerder zei, de lifespan van een enkel script is gewoon veel te kort om allerlei relaties tussen objecten te leggen.

Ook als je in een korte lifespan veel code moet uitvoeren kan het handig zijn om de boel in OO op te zetten. Je zegt het zelf geloof ik al hier in deze thread. Wat is belangrijker; de snellere development/betere onderhoudbaarheid of de performance?

In een Java-webapp waar ik mee bezig ben hebben de objecten vooral een lange levensduur doordat ze gecached worden of via factories worden gebouwd om hergebruikt te kunnen worden na een "reset" of omdat ze toch stateless zijn. Niet omdat er in het ontwerp nou ruimte was om objecten een lang leven te geven.

[Verwijderd]

Agreed.

Nogmaals, OOP is een programmeerparadigma en geen technisch snufje in je taal.

Ondersteunt PHP OOP? Jazeker. In OOP bestaat je programma niet uit functieaanroepen en lusjes maar uit objecten die met elkaar gegevens uitwisselen. Dit is in PHP zeer wel te realiseren. Tuurlijk kun je het ook procedureel emuleren, maar PHP heeft al wat ingebouwde voorzieningen hiervoor. Mooi toch?

Is het nuttig? Debatteerbaar: het programmeren wordt makkelijker met objecten maar vanwege de korte levensduur van scriptjes introduceert uitgebreid OOP programmeren misschien een te grote overhead.

Ondersteunt PHP alle features van OOP? Nee, en dat beweert ook niemand. Maar is dat nodig? Ik denk het niet. PHP is over het algemeen al een "simpeler" taal, en het lijkt me niet verkeerd dat het hele OOP gebeuren dan ook wat lichtgewichter is uitgevoerd.

En als je echt uitgebreid OOP in al zijn glorie wilt gaan gebruiken, dan ga je toch in Eiffel programmeren. Dan zie ik je over twee weken terug, na je eerste "hello world" programmaatje .

_{Overigens was dit niet een poging Eiffel te dissen. Ik vind het een geweldige taal; hij is alleen niet zo heel erg praktisch, en de omgeving EiffelStudio is een draak van een ding.}

[ Voor 6% gewijzigd door Verwijderd op 02-11-2004 13:07 ]

[alienfruit]

Als je Eiffel leukt vindt, kun je misschien eens kijken naar Chrome.NET dit is een pascal taal die wat Eiffel functionaliteit bied zoals Design By Contract (mooie feature trouwens )

[.oisyn]

ACM schreef op 02 november 2004 @ 12:10:
Zolang je functies op de klasse aanroept, die iets interns doet waar je aanroeper verder geen weet van hoeft te hebben is er imho al (een vorm van) encapsulatie.
Dat dat dan bij Java, C# en anderen veel mooier en stricter uitgevoerd kan worden doet daar niks aan af.

En in Java en C# kun je ook procedureel programmeren, door alle methodes static te maken of gewoon geen zinnige content in een class te definieren en gewoon van alles 1 object aanmaken.
Dat is echter niet de issue, de issue was of het nuttig is PHP (en ja ik weet dat ik verkeerd ben begonnen door aan de kaak te stellen of PHP überhaupt wel OO ondersteunt)

Ook als je in een korte lifespan veel code moet uitvoeren kan het handig zijn om de boel in OO op te zetten. Je zegt het zelf geloof ik al hier in deze thread. Wat is belangrijker; de snellere development/betere onderhoudbaarheid of de performance?

Ik had het over grote applicaties. Een PHP script noem ik geen grote applicatie, mijn forum is ook allesbehalve OO opgezet terwijl ik over het algemeen wel denk en implementeer volgens dat paradigima. Het had gewoon geen enkel nut, het script loopt gewoon van begin tot eind en doet een paar lees en schrijf-acties. Alle data gooide ik in geassocieerde arrays, ik heb echt geen nut gezien om dat onder te brengen in een object. Je zou bijvoorbeeld een Topic kunnen maken met een functie moveTo ($forum_id) om 'm te verplaatsen. Het enige wat die functie echter doet is een database functie aanroepen, dus waarom dan niet meteen een db_topic_move ($topic_id, $forum_id) aanroepen?

De reden van het 'nutteloze OO' is denk ik, naast de korte lifespan van een script, dat PHP de geassocieerde array feature kent, zonder die feature ga je al snel 'objecten' definieren zoals je structs en classes zou definieren in C++ en java. In PHP heb je dat niet echt nodig, je gooit gewoon alles in een array.

In een Java-webapp waar ik mee bezig ben hebben de objecten vooral een lange levensduur doordat ze gecached worden of via factories worden gebouwd om hergebruikt te kunnen worden na een "reset" of omdat ze toch stateless zijn. Niet omdat er in het ontwerp nou ruimte was om objecten een lang leven te geven.

Als ik mijn forum zou implementeren in een statefull systeem waarbij objecten blijven leven tussen requests zou ik het ook veel meer OO opgezet hebben, omdat je dan veel makkelijker dingen kunt cachen.

[Soultaker]

Erkens schreef op 02 november 2004 @ 08:28:
Waarom zou je door gebruik van OOP niet snel een resultaat kunnen geven, en wat is snel, zelf zie ik liever een kortere development tijd door het hergebruik van code dan dat ik een paar milliseconden win op de uitvoer.

Door een klasse te maken in plaats van een paar functies wordt je code echt niet magischerwijs beter herkbruikbaar. Zelf probeer ik allerlei code (PHP, maar ook bijvoorbeeld, C) enigzins herbruikbaar op te zetten. Dat lukt me in C minstens net zo goed als in object-georienteerde talen als C++ of Java (en vaak nog wel beter, op de een of andere manier).

Uiteraard is hergebruik en een lage ontwikkeltijd fijn, maar de vraag is welke rol OOP daar in speelt. Zoals ik al eerder noemde: het is tekenend dat de PHP standard library en extra modules (die erg uitgebreid zijn en de primaire reden vormen dat PHP zo'n succes is geworden) allemaal procedureel zijn opgezet. Er komt geen object bij kijken; misschien kun je als PHP module niet eens klassen exporteren.

[Stephan Oudmaijer]

Soultaker schreef op 02 november 2004 @ 22:18:
[...]

Door een klasse te maken in plaats van een paar functies wordt je code echt niet magischerwijs beter herkbruikbaar. Zelf probeer ik allerlei code (PHP, maar ook bijvoorbeeld, C) enigzins herbruikbaar op te zetten. Dat lukt me in C minstens net zo goed als in object-georienteerde talen als C++ of Java (en vaak nog wel beter, op de een of andere manier).

Uiteraard is hergebruik en een lage ontwikkeltijd fijn, maar de vraag is welke rol OOP daar in speelt. Zoals ik al eerder noemde: het is tekenend dat de PHP standard library en extra modules (die erg uitgebreid zijn en de primaire reden vormen dat PHP zo'n succes is geworden) allemaal procedureel zijn opgezet. Er komt geen object bij kijken; misschien kun je als PHP module niet eens klassen exporteren.

Misschien meteen de reden dat php ook voor grotere enterprise systemen NIET wordt gebruikt???

I rest my case...

[Erkens]

Soultaker schreef op 02 november 2004 @ 22:18:
[...]

Door een klasse te maken in plaats van een paar functies wordt je code echt niet magischerwijs beter herkbruikbaar. Zelf probeer ik allerlei code (PHP, maar ook bijvoorbeeld, C) enigzins herbruikbaar op te zetten. Dat lukt me in C minstens net zo goed als in object-georienteerde talen als C++ of Java (en vaak nog wel beter, op de een of andere manier).

Je code wordt imo overzichtelijker door het gebruik van klassen, waarbij het grootste voordeel is dat de functies makkelijker met elkaar kunnen communiceren dan zonder klassen want in dat geval heb je of veel global variabelen of een hele lijst aan argumenten, geen van beide kan ik aanraden iig

Uiteraard is hergebruik en een lage ontwikkeltijd fijn, maar de vraag is welke rol OOP daar in speelt. Zoals ik al eerder noemde: het is tekenend dat de PHP standard library en extra modules (die erg uitgebreid zijn en de primaire reden vormen dat PHP zo'n succes is geworden) allemaal procedureel zijn opgezet. Er komt geen object bij kijken; misschien kun je als PHP module niet eens klassen exporteren.

mja dat OO moet gewoon groeien en dat zie je ook met PHP5

[Stephan Oudmaijer]

.oisyn schreef op 02 november 2004 @ 15:28:
[...]


En in Java en C# kun je ook procedureel programmeren, door alle methodes static te maken of gewoon geen zinnige content in een class te definieren en gewoon van alles 1 object aanmaken.
Dat is echter niet de issue, de issue was of het nuttig is PHP (en ja ik weet dat ik verkeerd ben begonnen door aan de kaak te stellen of PHP überhaupt wel OO ondersteunt)


[...]


Ik had het over grote applicaties. Een PHP script noem ik geen grote applicatie, mijn forum is ook allesbehalve OO opgezet terwijl ik over het algemeen wel denk en implementeer volgens dat paradigima. Het had gewoon geen enkel nut, het script loopt gewoon van begin tot eind en doet een paar lees en schrijf-acties. Alle data gooide ik in geassocieerde arrays, ik heb echt geen nut gezien om dat onder te brengen in een object. Je zou bijvoorbeeld een Topic kunnen maken met een functie moveTo ($forum_id) om 'm te verplaatsen. Het enige wat die functie echter doet is een database functie aanroepen, dus waarom dan niet meteen een db_topic_move ($topic_id, $forum_id) aanroepen?

De reden van het 'nutteloze OO' is denk ik, naast de korte lifespan van een script, dat PHP de geassocieerde array feature kent, zonder die feature ga je al snel 'objecten' definieren zoals je structs en classes zou definieren in C++ en java. In PHP heb je dat niet echt nodig, je gooit gewoon alles in een array.


[...]


Als ik mijn forum zou implementeren in een statefull systeem waarbij objecten blijven leven tussen requests zou ik het ook veel meer OO opgezet hebben, omdat je dan veel makkelijker dingen kunt cachen.

Ik denk dat de hele reden dat php minimaal object georienteerd is omdat je vrijwel alleen met de frontend van een systeem te maken hebt. Er zijn weinig php projecten waar een php code base company breed wordt hergebruikt, en waar meerdere applicaties op de zelfde code draaien.

Opzich is een ook opzet in php helemaal niet zo gek om nog enigsinds business rules te kunnen hergebruiken op een nette manier, en om verantwoordelijkheden bij objecten te leggen ipv in procedures. Het geeft je daarnaast nog de mogelijkheid om generiek gedrag op een hoog niveau te definieren.

[.oisyn]

CK schreef op 02 november 2004 @ 22:38:
Ik denk dat de hele reden dat php minimaal object georienteerd is omdat je vrijwel alleen met de frontend van een systeem te maken hebt. Er zijn weinig php projecten waar een php code base company breed wordt hergebruikt, en waar meerdere applicaties op de zelfde code draaien.

Mja, PHP is nou niet echt van een business kaliber. Ik denk niet dat er bewust voor gekozen dat OO niet in PHP is gekomen omdat de bedrijven die ermee werken het niet snel nodig hebben. Want laten we wel wezen, het blijft een uit de hand gelopen hobbyproject. Ik denk dat een groot deel van de community vooral hobbyisten zijn, veel professionele grote webdevelopers neigen al snel naar platformen als ASP

[ Voor 11% gewijzigd door .oisyn op 02-11-2004 23:18 ]

[Tux]

.oisyn schreef op 02 november 2004 @ 23:17:
[...]


Mja, PHP is nou niet echt van een business kaliber. Ik denk niet dat er bewust voor gekozen dat OO niet in PHP is gekomen omdat de bedrijven die ermee werken het niet snel nodig hebben. Want laten we wel wezen, het blijft een uit de hand gelopen hobbyproject. Ik denk dat een groot deel van de community vooral hobbyisten zijn, veel professionele grote webdevelopers neigen al snel naar platformen als ASP

Een uit de hand gelopen hobbyproject kan best professioneel zijn hoor . Alleen moet ik in het geval van PHP inderdaad wel je mening delen. Omdat het als hobbyproject is begonnen, en de groep ontwikkelaars verandert natuurlijk van tijd tot tijd, is er niet echt een vaste filosofie achter PHP. Terwijl bij talen als C++ heel duidelijk is te zien dat het vanuit een vaste filosofie ontwikkeld is.

[PrisonerOfPain]

Soultaker schreef op 02 november 2004 @ 22:18:
[...]
Uiteraard is hergebruik en een lage ontwikkeltijd fijn, maar de vraag is welke rol OOP daar in speelt. Zoals ik al eerder noemde: het is tekenend dat de PHP standard library en extra modules (die erg uitgebreid zijn en de primaire reden vormen dat PHP zo'n succes is geworden) allemaal procedureel zijn opgezet. Er komt geen object bij kijken; misschien kun je als PHP module niet eens klassen exporteren.

DOM Xml is misschien een leuk voorbeeld? Toch ben ik er zelf voor om meer met OOP te doen in PHP, zeker 5 (welke wel polymorfie, overerving en encapsulatie kent). Daarbij is die procedurele aanpak natuurlijk ook niet alles, neem bijvoorbeeld de handles die je overal een en weer mag zeulen, of de 'input' parameter bij iedere string functie.
Waar ik me overigens dood aan kan ergeren zijn de pseudo classes zoals Directory, gewoon function's mappen (niets mis mee, tot je er zelf een variant op wilt maken...) Met DirectoryIterator in PHP5 heb ik nog geen ervaring, maar dat ziet er al een stuk beter uit.

[Verwijderd]

.oisyn schreef op 02 november 2004 @ 23:17:
[...]
Ik denk dat een groot deel van de community vooral hobbyisten zijn, veel professionele grote webdevelopers neigen al snel naar platformen als ASP

offtopic:
Wat toch gek is, want ASP is een draak van een ding. Maar ja, het wordt "ondersteund"

[mrFoce]

ik ben nog steeds van mening dat het er alleen maar 'profesioneler' uitziet en dat het niet echt nodig is.. Persoonlijk vind ik het er maar ingewikkeld uitzien, ben ok verscheidende forums overal in de wereld deze discussie tegengekomen en het is zeker een 'hobbyproject' van een van de makers van php.

Met php5 is het echter wel bruikbaarder geworden dan met php4.

[Mithrandir]

gideon82 schreef op 07 november 2004 @ 01:32:
ik ben nog steeds van mening dat het er alleen maar 'profesioneler' uitziet en dat het niet echt nodig is.. Persoonlijk vind ik het er maar ingewikkeld uitzien, ben ok verscheidende forums overal in de wereld deze discussie tegengekomen en het is zeker een 'hobbyproject' van een van de makers van php.

Met php5 is het echter wel bruikbaarder geworden dan met php4.

Eh, ingewikkeld uitzien? Ik snap je mening niet helemaal. OOP ziet er in het algemeen misschien ingewikkeld uit, maar we hebben het hier over een specifiek implementatie van (een soort van?) OOP.

Ik mis zelf de non-stateless-ness van een normaal programma. Om overal objecten van te maken die na één of twee calls ook weer wegkunnen, vind ik zonde van de overhead.

Wat je er voor terugkrijgt - leesbare code? Betere structuur? Ik ben zelf nu zo ver dat ik een heleboel dingen die ik in eerste instantie in een objectstuctuur heb gedaan op mijn site, nu weer teruggebracht heb tot procedureel programmeren. Misschien lag het aan mijn implementatie, misschien lag het aan het feit dat ik iets verkeerd deed, maar ik blijf OOP in PHP het grootste deel van de tijd onzin.

Een array mappen in een object is leuk, maar voor de meeste dingen die je wilt doen totaal overbodig.

[Brakkie]

gideon82 schreef op 07 november 2004 @ 01:32:
ik ben nog steeds van mening dat het er alleen maar 'profesioneler' uitziet en dat het niet echt nodig is.. Persoonlijk vind ik het er maar ingewikkeld uitzien, ben ok verscheidende forums overal in de wereld deze discussie tegengekomen en het is zeker een 'hobbyproject' van een van de makers van php.

Met php5 is het echter wel bruikbaarder geworden dan met php4.

Met Zend als belangrijke pilaar onder PHP kun je het op dit moment echt geen hobbyproject meer noemen. http://www.zend.com/company/overview.php

Verder is OOP gebruiken in php in mijn ervaring bevorderlijk voor de overzichtelijkheid en de onderhoudbaarheid van een applicatie.

[Mithrandir]

Brakkie schreef op 07 november 2004 @ 18:12:
[...]


Met Zend als belangrijke pilaar onder PHP kun je het op dit moment echt geen hobbyproject meer noemen. http://www.zend.com/company/overview.php

Verder is OOP gebruiken in php in mijn ervaring bevorderlijk voor de overzichtelijkheid en de onderhoudbaarheid van een applicatie.

Jammer alleen is dat ze backward compatibility willen behouden. Als ze alle functienamen eens over de kop gingen halen of de error-handling compleet zouden maken, zou dat een veel grotere stap voorwaarts zijn dan de (amper verbeterde) OO ondersteuning.

[Creepy]

Verwijderd schreef op 03 november 2004 @ 01:56:
[...]

offtopic:
Wat toch gek is, want ASP is een draak van een ding. Maar ja, het wordt "ondersteund"

offtopic:
En .oisyn vergeet voor het gemakt jsp en cgi. Want ook die worden stiekum nog vrij vaak gebruikt

[ Voor 3% gewijzigd door Creepy op 08-11-2004 09:27 ]

[.oisyn]

Creepy schreef op 07 november 2004 @ 23:14:
[...]

offtopic:
En .oisyn vergeet voor het gemakt jsp en cgi. Want ook die worden stiekum nog vrij vaak gebruikt

CGI is geen taal en jsp is geen scripttaal zoals php en jscript/vbscript onder het asp platform zijn (want in feite kun je vrijwel alles gebruiken om een webapplicatie te maken, dat was hier echter niet de issue). En voor het geval je perl bedoelde: dat is een living hell

[ Voor 7% gewijzigd door .oisyn op 08-11-2004 12:21 ]

[Creepy]

.oisyn schreef op 08 november 2004 @ 12:20:
[...]


CGI is geen taal en jsp is geen scripttaal zoals php en jscript/vbscript onder het asp platform zijn (want in feite kun je vrijwel alles gebruiken om een webapplicatie te maken, dat was hier echter niet de issue). En voor het geval je perl bedoelde: dat is een living hell

Scripttaal? Meer als "platformen" waar "veel professionele grote webdevelopers" naar neigen
(of CGI dan een platform is valt nog te betwisten)

[Verwijderd]

Lekker belangrijk of iets het OO predicaat mag ontvangen. Het zal me echt aan me reet roesten of OO requirement A en B er in moeten zitten om aan dat predikaat te voldoen. Zolang jij met de functionaliteit die dat benadert effectief tijd kan besparen, code kunt hergebruiken, structuur kunt creeren en voor de toekomst minder onderhoud hoeft te plegen aan je applicaties(s) lijkt me het zo klaar als een klontje dat je de voordelen van echt OO te pakken hebt. Wat interesseert het verder dan nog dat er niet het labeltje OO aan hangt.