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....
>> • 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?
---------------------------------------------------------- [color="red"]@R van der Meer[/color]
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?
>> 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
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.
- 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?
Het is hier gezellig hoor Aar! :)
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)
>> 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?
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.
