Waarom OO?!
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:
Quote:
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?
Ozzie PHP op 28/11/2013 14:31:37:
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.
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.
Toevoeging op 28/11/2013 15:03:20:
Ozzie PHP op 28/11/2013 14:46:06:
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?
Quote:
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).
Gewijzigd op 28/11/2013 15:01:23 door Erwin H
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.
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.
R van der Meer op 28/11/2013 15:17:25:
Moet ik bovenstaande ook lezen of verzorgt het alleen maar meer verwarring?
Ik vrees dat je topic gekaapt is.
Was jouw vraag helemaal beantwoord?
Ozzie PHP op 28/11/2013 15:33:28:
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.
>> • interface: je moet deze methoden implementeren;
Duidelijk!
>> • abstract class: deze methoden zijn al voor je geïmplementeerd.
Kan ik daar dan uit afleiden dat jij in een abstract class nooit abstract methods hebt staan?
@Erwin:
>> 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.
Dit snap ik volledig.
>> Heeft de abstracte class die methode al nodig, omdat er bijvoorbeeld ergens een btw berekening wordt gedaan...
Dit snap ik nog niet. Bedoel je dat een andere method in die abstracte class de abstract method gebruikt? Dus dat de method intern door de abstracte class wordt gebruikt, of bedoel je iets anders?
----------------------------------------------------------
@R van der Meer
Ik dacht een simpele vraag te stellen, maar dat bleek toch niet zo te zijn waardoor ik onbedoeld je topic heb gekaapt. Hiervoor mijn excuses. Is jouw vraag inmiddels beantwoord, of zijn er nog onduidelijkheden?
----------------------------------------------------------
Ozzie PHP op 28/11/2013 18:59:44:
>> Heeft de abstracte class die methode al nodig, omdat er bijvoorbeeld ergens een btw berekening wordt gedaan...
Dit snap ik nog niet. Bedoel je dat een andere method in die abstracte class de abstract method gebruikt? Dus dat de method intern door de abstracte class wordt gebruikt, of bedoel je iets anders
Dit snap ik nog niet. Bedoel je dat een andere method in die abstracte class de abstract method gebruikt? Dus dat de method intern door de abstracte class wordt gebruikt, of bedoel je iets anders
Precies. Dat is in mijn ogen de enige reden waarom je een abstracte methode in een class maakt (die daarmee dan automatisch zelf abstract moet worden). Dit doe je om zo de afgeleide class de implementatie te laten verzorgen, maar er wel al in de abstracte class vanuit te kunnen gaan dat dat zal gebeuren. Omdat dit puur intern gebeurt (protected methodes), heeft het om die reden geen zin om het in een interface te zetten.
Grrrrrrrrr..........
- een abstract class gebruik je om functionaliteit te bundelen
- een abstract method is een method die door de abstracte class zelf wordt gebruikt, maar moet worden geimplementeerd door de child class
- een interface gebruik je om methods verplicht te stellen die van buitenaf moeten kunnen worden aangeroepen
Kun je dan stellen dat een abstract method nooit van buitenaf moet worden gebruikt en dus altijd protected zal zijn? Immers, als je de method wel van buitenaf moet kunnen gebruiken, dan is het een interface. Is mijn conclusie correct?
>> 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.
Bedoel je dan dat je een method foo hebt, die je als abstracte method foo in de abstracte class opneemt én in de interface? Wat is daar dan het voordeel van? Als je foo in de interface zou zetten, dan moet foo dus in de child classes aanwezig zijn. Waarom zou je foo dan nog als abstract method plaatsen? Dat is toch dubbelop?
- Aar -:
Heren, zullen we het gezellig houden, en ontopic blijven?
Dat lijkt mij het beste....
Als Ozzie zelf nog andere vragen heeft mag hij daarvoor een nieuw topic starten. Een topic kapen is niet de bedoeling.
Dat lijkt mij het beste....
Als Ozzie zelf nog andere vragen heeft mag hij daarvoor een nieuw topic starten. Een topic kapen is niet de bedoeling.
Gewijzigd op 28/11/2013 20:24:48 door - Ariën -
Alleen Ger is boos omdat ik (onbedoeld) een topic heb gekaapt. Ik ga er vanuit dat de topicstarter zich zal melden als hij nog meer wil weten (zie mijn oproep). Ik kan ook een nieuw topic beginnnen, maar aangezien de vraag bijna is beantwoord en we dan de gespreksgeschiedenis in dat topic missen lijkt me dat wat zinloos. Ik wacht nog even op het antwoord van Erwin en dan weet ik voldoende. En zodra de topicstarter zich weer meldt kunnen we weer vol gas on topic.
(volgende keer zal ik overigens wel een nieuw topic starten... ik had alleen gedacht dat mijn vraag iets simpeler in 1x te beantwoorden was... excuus)
Gewijzigd op 28/11/2013 20:27:42 door Ozzie PHP
Ozzie PHP op 28/11/2013 19:59:47:
>> 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.
Bedoel je dan dat je een method foo hebt, die je als abstracte method foo in de abstracte class opneemt én in de interface? Wat is daar dan het voordeel van? Als je foo in de interface zou zetten, dan moet foo dus in de child classes aanwezig zijn. Waarom zou je foo dan nog als abstract method plaatsen? Dat is toch dubbelop?
Bedoel je dan dat je een method foo hebt, die je als abstracte method foo in de abstracte class opneemt én in de interface? Wat is daar dan het voordeel van? Als je foo in de interface zou zetten, dan moet foo dus in de child classes aanwezig zijn. Waarom zou je foo dan nog als abstract method plaatsen? Dat is toch dubbelop?
Je hebt er dus nog steeds niets van begrepen... Dat heb ik namelijk eerder uitgelegd. En verder begrijp ik dat hier antwoorden niet meer op zijn plaats is.