[php] OO programmeren in php4

[Apollo_Futurae]

Ik heb maar een nieuw topic geopend om het topic van int niet verder te vervuilen .

===================

Mijn stelling is: php4 heeft een oo-implementatie die toereikend is voor de applicaties waarvoor php bedoeld is.

Ik heb eigenlijk niet zo veel recht van spreken; ik ben ooit toen ik +- 10 jaar was begonnen met java (eerste programmeerervaring ), maar er ook gauw weer mee gestopt (vond er niets aan) en ik ben net pas begonnen met het oo-programmeren in php.
Wat ik tot nu toe allemaal heb geprobeerd (ben bezig met een abstractie-class voor html formulieren) gaat echter prima (ook overerving en het doorgeven van objecten).

Zef noemde in het topic van int als minpunten o.a. het ontbreken van interfaces en van overloading van methods.

Om met de laatste te beginnen; hieraan wordt gewerkt.
Kijk maar eens hier:
PHP: Object property and method call overloading - Manual
Zelf heb ik er nog niet echt goed naar gekeken en ik kan dus ook niet beoordelen of het bruikbaar is.

Wat betreft interfaces, ik begrijp niet helemaal wat de toegevoegde waarde ervan is.
Het is een prima hulp voor het opbouwen van een (gemoduleerde) objectboom (ik weet niet of ik deze woorden goed gebruik, maar ze klinken wel goed ), maar als je van tevoren een goed ontwerp maakt heb je geen interfaces nodig.
Of zijn er situaties denkbaar waarin interfaces absoluut noodzakelijk zijn?

Verder heb ik het idee dat deze en andere wat meer 'geavanceerde' oo-functies niet belangrijk zijn voor een webscriptingtaal als php.

[mbravenboer]

Ik ga geen hele vergelijking opzetten want dat is veel te veel werk en bovendien een subjectief iets. De vraag of de OO functionaliteit in PHP voldoet voor de applicaties die je erin zou moeten bouwen is nog veel subjectiever, dus die laat ik ook aan anderen over .

Eerst even een eerdere topic:
[topic=211533/1/25]
en deze:
[topic=368275/1/25]

Nog even uit dat andere topic over dat boek, waar dit topic uit onstond:

Apollo_Futurae: In php4 daarentegen is het allemaal prima geregeld. Ik vind php4 nauwelijks voor java onderdoen (qua oo dan).

Tja, toch leuk dat ze private variabelen nog niet als private behandelen . Qua design zit het verder inderdaad wel aardig in elkaar.

er zijn uiteraard wel minpuntjes, waarvan de standaard pass-by-value misschien nog wel de lastigste is.

Met termen als pass-by-value moet je uitkijken: in Java is alles namelijk ook pass-by-value omdat de pointer naar het object by-value wordt meegegeven. Dat is prettig omdat als deze by-reference zou worden meegegeven je lokale variabelen van de aanroepende methode zou kunnen aanpassen. Dat wil je eigenlijk nooit, net zoals out variabelen imho vreemd en niet nuttig zijn (liever zie ik dan een ingebouwde notie van tuples).

Wat betreft interfaces, ik begrijp niet helemaal wat de toegevoegde waarde ervan is.

Dat zie ik toch echt anders: interfaces zijn een manier om te beschrijven wat voor mogelijkheden een object heeft. Het is een specificatie van mogelijkheden/capaciteiten die een bepaalde verzameling klassen heeft (namelijk die klassen die de interface implementeren). Je kunt via deze specificatie werken met instanties van al deze klassen, onafhankelijk van de implementatie. Dit is een krachtig mechanisme wat ook wel polymorphisme wordt genoemd.

Interfaces zijn een prettige mechanisme om met instanties van onbekende implementaties te werken: de implementatie is namelijk niet relevant omdat je via de interface (de specificatie) kunt werken. Je kunt zo generieke code schrijven die werkt op deze interfaces.

maar als je van tevoren een goed ontwerp maakt heb je geen interfaces nodig.

Ik denk dus dat interfaces niet zozeer iets te maken hebben met het maken van een goed ontwerp of niet. Interfaces beschrijven capaciteiten van instanties van een hele verzameling klassen en dat is een krachtig begrip.

Of zijn er situaties denkbaar waarin interfaces absoluut noodzakelijk zijn?

Mwah, Java zou best Turing compleet zijn zonder interfaces, dus dat is in ieder geval niet zo . Of interfaces in een taal als PHP nuttig zijn of binnen het conceptp van de taal passen, is een hele andere vraag en ....daar ga ik dus niets over zeggen .

Hier nog een stukje wat ik een tijd geleden op Javahova schreef over interfaces:

Interfaces... Je kan het op twee manieren bekijken: conceptueel en technisch gezien. Als je conceptueel naar interfaces kijkt, heb je het over de gedachte achter interfaces: waarom heb je interfaces nodig en welke rol vervullen ze? Als je technisch gezien naar interfaces kijkt, kijk je wat interfaces aan constructies kunnen bevatten en wat klassen moeten doen die in een interface implementeren.

Het technische aspect is niet zo interessant omda het details zijn. Het gaat om het concept van interfaces, daarom zal ik daar iets over zeggen .

Een interface geeft capaciteiten aan. Een interface zelf is een beschrijving van een bepaalde capaciteit. Goede voorbeelden in standaard Java library zijn:

Runnable: iets wat Runnable 'is' kan je 'runnen'. De Runnable interfaces biedt deze capaciteit via de methode 'run'.

Comparable: iets wat Comparable 'is' kan je vergelijken met andere items. De Comparable interface biedt deze capaciteit via de methode 'compareTo'.

List: iets wat een List 'is' kan je behandelen als een List: je kan er items aan toevoegen, verwijderen, invoegen, items opvragen aan de hand van een index enzovoorts.

Comparator: een Comparator is een ding wat kan vergelijken: je stopt er twee items in en de Comparator levert de vergelijking van deze twee op.

Allereerst zie je in dit rijtje twee dingen opvallen. De interfaces geven namelijk een beschrijving van hoe je iets kunt gebruiken. De manier waarop dit gebruik is geimplementeerd verschilt juist per situatie. Daarom bevat een interfaces dus geen implementaties. Een interface geeft echter wel een beschrijving hoe je een implementatie die een bepaald doel heeft op een standaard manier kunt gebruiken.

Je zit in het lijstje van voorbeelden hierboven steeds het woordje 'is' terugkomen. Dit 'is' is precies de betekenis van het keyword 'implements'. Een interface beschrijft namelijk capaciteiten en door middel van het implementeren van de interface (implements X) geef je aan dat deze klasse deze capaciteiten bezit. Je geeft daarmee in feite aan dat de implementatie van de methoden in de klasse overeenkomt met het doel wat gedefinieerd is in de interface.

Met het uitbreiden van superklassen (extends) kan je dus code, implementaties hergebruiken en specialiseren of uitbreiden. Als je een interface implementeert hergebruik je geen code: je geeft alleen maar aan dat deze klasse bepaalde capaciteiten bezit en je groepeert klassen ook min of meer in typen: 'Runnables', 'Comparatoren' en 'Comparables'.

Je kunt algorithmen implementeren die werken op een interface. Je kunt hierbij bijvoorbeeld denken aan de sort methode in de klasse Collections die een List en een Comparator meerkrijgt. Je geeft hiermee aan de je algoritme 'iets' nodig heeft wat de capaciteit van een Comparator moet hebben. Wat de implementatie van deze Comparator is, mag de gebruikers van het algoritme echter zelf weten.

Dit is een vorm van polymorphisme: meervormigheid. Het sorterings-algoritme kan namelijk werken op alles wat de capaciteit List en Comparator heeft. Wat de concrete implementatie van de twee is, maakt niet uit. Het algoritme werkt daardoor op meerdere vormen en is daardoor generiek.

Duidelijk?

[Apollo_Futurae]

Op zaterdag 22 juni 2002 21:20 schreef mbravenboer het volgende:
Dat zie ik toch echt anders: interfaces zijn een manier om te beschrijven wat voor mogelijkheden een object heeft. Het is een specificatie van mogelijkheden/capaciteiten die een bepaalde verzameling klassen heeft (namelijk die klassen die de interface implementeren). Je kunt via deze specificatie werken met instanties van al deze klassen, onafhankelijk van de implementatie. Dit is een krachtig mechanisme wat ook wel polymorphisme wordt genoemd.

Interfaces zijn een prettige mechanisme om met instanties van onbekende implementaties te werken: de implementatie is namelijk niet relevant omdat je via de interface (de specificatie) kunt werken. Je kunt zo generieke code schrijven die werkt op deze interfaces.

is dit niet mogelijk met de volgende php functies?
• get_class
• get_class_methods
• get_class_vars
• get_object_vars
• get_parent_class
• is_a
• is_subclass_of
• method_exists

[mbravenboer]

Apollo_Futurae: is dit niet mogelijk met de volgende php functies?

Het gaat sowieso niet om de mogelijkheid, maar om de vraag of de taal het concept op een prettige manier aanbied die iedereen op dezelfdee manier gebruikt en ook een vorm van specificatie biedt.

In een taal met een type-systeem als dat van PHP kan je uiteraard alles doen op dit gebied wat je maar wilt. Dit kan zelfs in Java of C# met behulp van reflectie ook wel (hetgene wat jij voorstelt is in feite ook reflectie).

Het is echter niet mogelijk om netjes in de taal te specificeren waaraan een bepaalde klassen moet voldoen om bijvoorbeeld in de categorie 'Comparable', 'Servlet', 'List' of 'Iterator' te vallen.

Het gaat dus om het vastleggen van de specificatie en het prettig gebruik daarvan. Een generiek algoritme zou best met behulp van reflectie uit kunnen zoeken of hij kan opereren op een bepaalde klasse, maar het is een stuk prettiger als hij gewoon werkt op een interface en de taal/omgeving garandeerd dat deze interface ook geimplementeerd wordt door de klasse van de instantie die wordt meegegeven.

Overigens lijkt het nu net alsof interfaces het 'hot topic' van object orientatie is en alsof het gebrek hieraan OO in PHP waardeloos maakt, maar dat is uiteraard niet zo: ik ging hier op in omdat het werd genoemd, maar zaken als inheritance en encapsulation spelen uiteraard een veel grotere rol. Encapsulation schijnt nu qua design een beetje gerealiseerd te zijn, maar in de implementatie nog niet. Dat is jammer.

_{Overigens kan je ook in Java bij private functionaliteit komen als er geen SecurityManager is}