Nu is deze vraag al waarschijnlijk 100 keer gesteld. Maar ik krijg het er bij mij zelf niet in waarom ik OO moet gaan gebruiken.
Ja, ik zie het voordeel van Object oriented programmeren. Maar ik zie niet waarom ik Classes moet gebruiken. Nu heb ik in de tijd dat ik van OO afweet in PHP tot nog toe nooit een echt groot project gehad waarvan ik zeg dat OO echt nodig is.
Nu ben ik echter bezig met een tool, waarbij ik echt volgens mij doen al OO werk, maar niet het voordeel zie van Classes etc...
Als ik dan zoek naar Waarom OO? krijg ik het antwoord "omdat je bepaalde functies kan her gebruiken" Dan kom ik eigenlijk tot de conclusie dat ik al OO denk wanneer ik bijvoorbeeld een centraal bestand heb met daarin functions die ik dus hergebruik.
Ook omdat ik bijvoorbeeld voor een inlog scherm al het bestand inlog.php include. (ik noem maar wat)en die aanpas als er wat moet gebeuren...
Nu ben ik dus niet opzoek waarom OO, maar ik ben eigenlijk opzoek die bij mij de knop kan omzetten om OO te gaan programmeren met de bijbehorende objecten, classes etc.
Ik kom ook nooit uit het voorbeeld van de auto... Boeiend dat deze blauw moet zijn...
Graag hoor ik het ook als ik echt compleet de bus mis en bovenstaande kant noch wal raakt.. Ik probeer bij mij zelf die knop om te zetten....
Erwin thanks voor je reactie. Maar hoe zit het dan als je een class hebt die in feite al klaar is, maar waarvan nog 1 method door de child moet worden ingevuld? Dus bijv. het voorbeeld van Ward. Die heeft een abstracte betaal class, maar hij maakt van setAmount een interface.
Had hij volgens jou van setAmount ook een abstract method in de abstract class kunnen maken en de interface laten vervallen? Ik had begrepen dat abstract methods daarvoor zijn bedoeld. Je hebt dus als het ware een "basisclass" waarvan een bepaalde method nog moet worden ingevuld door de child class.
Zoals ik op een andere website las en hierboven ook al citeerde:
Abstract classes look a lot like interfaces, but they have something more : you can define a behavior for them. It's more about a guy saying "these classes should look like that, and they got that in common, so fill in the blanks!".
Die setAmount method lijkt me dus exact in dit plaatje passen. De abstract payment class is klaar, maar de child class moet alleen nog even de gaten (in dit geval de setAmount method) opvullen. Of zie ik het verkeerd?
Kunnen jullie aub nog reageren op mijn 2 voorgaande berichten?
Ja, stel dat de baas van de pizzeria besluit te gaan thuisbezorgen. En niet alleen pizza, maar ook allerlei andere gerechten. Alle gerechten kunnen dan de ThuisbezorgenInterface delen, maar jij zit nog steeds met een abstract class die serve() voor in het restaurant voorschrijft én implementeert.
Je maakt het ingewikkelder dan het eigenlijk is. Een interface somt slecht public methoden op die moeten worden geïmplementeerd. Een abstract class kan al methoden implementeren, alleen kun je er geen objecten mee instantiëren.
Als je een abstract class maakt met uitsluitend lege abstract methods, dan is het eigenlijk een interface. En dan kun je beter een interface gebruiken, want die maakt zelfstandige klassen mogelijk die niet verplicht via extends afhankelijk zijn van een andere klasse, maar wel een gemeenschappelijke, gestandaardiseerde API hebben.
>> Als je een abstract class maakt met uitsluitend lege abstract methods, dan is het eigenlijk een interface. En dan kun je beter een interface gebruiken, want die maakt zelfstandige klassen mogelijk die niet verplicht via extends afhankelijk zijn van een andere klasse, maar wel een gemeenschappelijke, gestandaardiseerde API hebben.
Oké, dit begrijp ik. Alleen de scheidslijn wanneer je een abstract class met abstract method versus een interface gebruikt vind ik nog wat onduidelijk. Als ik kijk naar jouw payment class, die is eigenlijk al helemaal klaar, de werking is bekend, alleen moet er nog aan 1 method (setAmount) invulling worden gegeven. Waarom kies je er in dit geval voor om die ene method in een interface te stoppen en niet als abstracte method in de abstracte class? (Ik zeg niet dat jouw oplossing fout is hè! Ik wil alleen weten waarom jij voor een interface kiest zodat ik het beter begrijp.)
Ik heb zelf een abstract autoloader class. Die class bezit alle methods die nodig zijn om de namespaces en de bijbehorende directories in te stellen. Het enige wat per autoloader verschilt, is de loadClass method. Daarom heb ik daar in de abstracte class een abstract method van gemaakt. Is dat dan verkeerd en had dat een interface moeten zijn?
Een abstracte class heeft als doel bepaalde functionaliteit te bundelen zodat code niet dubbel hoeft te worden geschreven.
Een interface heeft als doel om af te dwingen dat classes bepaalde methodes (en eventueel ook constantes) publiceren.
Bedenk dus elke keer om welke van de twee redenen je iets wilt doen en bepaal aan de hand daarvan of je een abstracte class of een interface nodig hebt. In sommige gevallen zal je zelfs beide willen gebruiken, met zelfs in beide dezelfde methodes.
[size=xsmall]Toevoeging op 28/11/2013 15:03:20:[/size]
Ozzie PHP op 28/11/2013 14:46:06
Abstract classes look a lot like interfaces, but they have something more : you can define a behavior for them. It's more about a guy saying "these classes should look like that, and they got that in common, so fill in the blanks!".
Die setAmount method lijkt me dus exact in dit plaatje passen. De abstract payment class is klaar, maar de child class moet alleen nog even de gaten (in dit geval de setAmount method) opvullen. Of zie ik het verkeerd?
Foute quote wat mij betreft van iemand die het concept niet helemaal begrijpt (of je hebt een essentieel deel van de tekst weggelaten).
>> Moet ik bovenstaande ook lezen of verzorgt het alleen maar meer verwarring?
Nee... laat maar even buiten beschouwing :)
>> Een abstracte class heeft als doel bepaalde functionaliteit te bundelen zodat code niet dubbel hoeft te worden geschreven. Een interface heeft als doel om af te dwingen dat classes bepaalde methodes (en eventueel ook constantes) publiceren.
Erwin, oké. Ik volg je aardig! Ben alleen dus wel benieuwd waar in dit plaatje dan een abstract method (binnen een abstracte class) thuishoort?
Ik val weer even terug op het voorbeeld van Ward. Ward heeft een abstracte betaal class. Volgens jouw omschrijving gebruik je die met als doel bepaalde functionaliteit te bundelen zodat code niet dubbel hoeft te worden geschreven. Dat lijkt me te kloppen. Nu heeft Ward de setAmount method in een interface gezet, maar je kunt er ook voor kiezen om geen interface te gebruiken maar de setAmount method als abstract method op te nemen in de abstracte betaal class. En nu zou ik heel graag weten wat het verschil tussen beide manieren is.
Een abstract methode was inderdaad ook acceptabel. Er is hier niet echt een goed of fout, meer een keuze. Erwin omschrijft het mooi: de interface is een publicatie, een handleiding en een contract. Juist omdat de interface maar één regel voorschrijft, zijn de voorschriften meteen duidelijk.
Persoonlijk vind ik dit onderscheid het prettigst werken, en het duidelijkst, maar ergens is het inderdaad een keuze die je consequent moet doorvoeren:
• interface: je moet deze methoden implementeren;
• abstract class: deze methoden zijn al voor je geïmplementeerd.
Waar ik me wel aan erger, is dat de interfaces van PHP te vergevensgezind zijn wat de signatures betreft.
Nu heeft Ward de setAmount method in een interface gezet, maar je kunt er ook voor kiezen om geen interface te gebruiken maar de setAmount method als abstract method op te nemen in de abstracte betaal class.
Nee, het is niet 'je kan er ook voor kiezen'. Het gaat erom waarom die methode nodig is.
Heeft de abstracte class die methode al nodig, omdat er bijvoorbeeld ergens een btw berekening wordt gedaan of weet ik veel, maar kan de echte waarde pas bepaald worden in de afgeleide class? -> dan moet de methode als abstracte methode in de abstracte class
Moet de methode worden afgedwongen voor alle classes, omdat er van buiten ook gebruik van moeten kunnen worden gemaakt? Dan stop je het in de interface.
Merk op, op beide vragen kan je ja antwoorden en het kan dus ook zonder problemen voorkomen dat je de methode in zowel abstracte class, als in de interface plaatst. Beide dienen een ander doel, dus het een sluit het ander niet uit! Het is dus niet of/of.
