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....
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.
Niets moet. Lijkt een dooddoener, maar wel de werkelijkheid. Als jij de voordelen niet ziet, dan zijn ze er blijkbaar niet (voor jou in elk geval). OO is niet de heilige graal die alles makkelijker of beter maakt. In tegendeel in veel gevallen
Henk Van der Plas op 27/11/2013 15:45:17
Ja, ik zie het voordeel van Object oriented programmeren. Maar ik zie niet waarom ik Classes moet gebruiken.
...
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...
Lijkt me een contradictio in terminis. Classes gebruiken, maar niet OO is mogelijk, andersom heb ik het nog nooit gezien. Als je dus OO gebruikt, dan gebruik je classes. Gebruik je geen classes, dan is je applicatie ook niet OO.
Lijkt me een contradictio in terminis. Classes gebruiken, maar niet OO is mogelijk, andersom heb ik het nog nooit gezien. Als je dus OO gebruikt, dan gebruik je classes. Gebruik je geen classes, dan is je applicatie ook niet OO.
Mijn inziens is het OO, niet omdat ik classes gebruik, maar omdat ik bepaalde onderdelen toch al weet her te gebruiken? Maar daarom zeg ik het ook. Die knop moet om waarom ik classes zou moeten gebruiken in plaats van functies.
Misschien ligt mijn denkbeeld van OO helemaal verkeerd en zit ik mis met OO is dat ik dingen hergebruik, ik kan een functie schrijven die e-mail voor mij verstuurd in een bepaalde opmaak. Nu heb ik van het internet een stukje "geleend" dat OO is (manier van schrijven) waarbij ik het zelfde e-mailtje kan versturen...
Is het dan in eens OO omdat het op die manier geschreven is? Of is OO niet de manier van programmeren, maar het hergebruiken van het stukje programmeer werk...
Ik bouw een object, mail versturen. Hoe die mail verstuurd wordt is irrelevant, zolang ik maar het zelfde mail versturen 5 pagina's verder weer kan gebruiken. EN als er wat aangepast moet worden dat ik het niet op pagina 1 en op 5 moet aan passen, maar op een plaats voor beide momenten dat je het gebruikt.
Ik ben geen OOP expert, integendeel, ik gebruik het nooit. Maar als je dit doorleest denk ik dat je heel wat wijzer word. Het is vooral handig voor erg grote projecten.
Mijn inziens is het OO, niet omdat ik classes gebruik, maar omdat ik bepaalde onderdelen toch al weet her te gebruiken?
Het feit dat je iets herbruikt heeft natuurlijk helemaal niets met OO te maken. Ik kan 1 regel code schrijven die 'hoi' naar het scherm stuurt, dit in een php bestand plaatsen en dat bestand dan te pas en te onpas includen. Dan herbruik ik code, maar het heeft natuurlijk geen bal te maken met OO.
OO (Object Oriented) gaat uit van het gebruiken van objecten die zelfstandig kunnen opereren. Die objecten kunnen binnen hun eigen verantwoordelijkheid beslissingen nemen, validatie toepassen en er zorg voor dragen dat bepaalde functionaliteit correct wordt uitgevoerd. Het is niet een functie 'die iets doet', maar een op zich zelfstaand onderdeel van je applicatie. Dit onderdeel kan je vervolgens ergens anders ook weer gebruiken. Het herbruiken van de code is echter een voordeel, niet een kenmerk.
Daarnaast is nog een enorm belangrijk onderdeel dat elke functionaliteit altijd maar op 1 plek in je code wordt gedefinieerd. Je hebt dus bijvoorbeeld 1 validatie class die alle validatie (voor een bepaald type) doet. Die class gebruik je overal en altijd waar je die validatie nodig hebt.
Thanks, Dus inderdaad wat ik aangeeft is dat het niet OO is, en de uitleg "OO = iets opnieuw gebruiken", die ik met enige regelmaat ben tegen gekomen, niet dekkend is.
Mooi. Dan probeer ik die gedachte over boord te gooien.
Maar als ik het dan betrek op een systeem waarbij ik gebruikers ga hebben en die moet aanmaken. Ik kan een functie schrijven die aangeroepen wordt na het verzenden van een formulier. Laten we die functie "nieuwe-gebruiker" noemen.
"nieuwe-gebruiker" bestaat uit het opslaan van de gegevens in de database en een e-mail naar deze nieuwe gebruiker toe te sturen.
Stel ik wil dat in objecten/classes onderbrengen. Ben ik dan op de juiste wijze aan het denken? Dat ik niet de functie aanroep, maar het object.
Waarbij ik dus een toevoeging doe aan de database. EN een mail stuur.
Ik zou dan twee objecten moeten maken.
"toevoegen" en "versturen"
Waarbij ik bijvoorbeeld het zelfde "versturen" weer kan gebruiken als ik een e-mail wil versturen bij een nieuw bericht (ik schud het nu even uit de mouw)
Alleen die hele e-mail heeft een totaal andere opmaak... Hoe verwerk ik dat dan?
Het "toevoegen" kan ook weer gebruikt worden, alleen dan in een andere tabel (berichten) met andere inhoud...
Nee. Je denkt nu in functies (functioneel programmeren), niet in objecten (object georienteerd programmeren).
In OOP is een object een entiteit, bijvoorbeeld een gebruiker, bijvoorbeeld een mailer, bijvoorbeeld een database, etc. Elk object heeft properties (de mailer kan bijvoorbeeld het property afzender hebben) en functionaliteiten (ook wel methodes genoemd in OOP). 'versturen' en 'toevoegen' zijn dus geen objecten, maar methodes van objecten.
Met je nieuwe gebruiker voorbeeld kan je dus een gebruiker object hebben (met alle kenmerken van de gebruiker), een database object (dat de data in de database toevoegt, of opslaat) en een mailer (dat de mail kan versturen).
En dit is een zeer versimpeld voorbeeld. Alleen je database object zal in het echt al minimaal uit 3 objecten bestaan (database-, connectie- en queryobject), maar al snel nog meer. Bedenk ook dat elk object uiteindelijk maar verantwoordelijk mag zijn voor 1 onderdeel van je applicatie. Je kan dus niet een mailer hebben die ook de content van de emails bepaalt. In dat geval krijg je namelijk al een probleem met het opnieuw gebruiken van dat object, want in een volgende applicatie zijn de mails heel anders.
(Okay, er is voldoende on topic geantwoord, zodat ik een zijsprong kan maken)
Php is niet de ideale taal wenneer je het nut van OOP wil uitleggen.
Vooral dan omdat php een verzoek regelt in 1 ogenblik (een aantal microseconden).
Beeld je even in dat je de zelfde vraag stelt, maar dan met een andere taal, bv. C++, C#, Java, ... om een applicatie (een GUI, een windows proggramma, ...) te maken.
Daar heb je een programma dat blijft draaien.
De variabelen blijven actief zolang het programma draait.
We maken een windows programma waarmee we een auto samenstellen. Voor het gemak gebruik ik php notatie.
Vanaf het programma wordt gestart wordt dit uitgevoerd:
$auto = new Auto();
Een minuut later heeft de gebruiker een kleur (van lak) gekozen.
Dan wordt dit uitgevoerd:
$auto->setColor('red');
Nog een minuut later kiest de gebruiker de cilinderinhoud
$auto->setCC(2200);
Snap je dat het in deze situatie handig is dat we 1 variabele hebben: $auto.
Alle eigenschappen van die auto worden verzameld in die ene variabele. -> dat zijn de eigenschappen of properties.
En niet alleen de eigenschappen, maar ook alle mogelijkheden; -> dat zijn de functies of de methods.
In php vallen sommige voordelen minder op, omdat alles sowieso in 1 ruk gebeurt.
Maar je snapt ook wel hoe dit begonnen is: programmmeurs uit een c++ of JAVA achtergrond beginnen php te scripten en denken: ik wil ook OOP kunnen gebruiken in php.
De rest is geschiedenis.
Dit soort reacties vind ik zo vreemd. Ik geef bovenstaand aan dat ik op een bepaalde manier zie, op een gegeven moment na 3/4 antwoorden lees ik dat mijn denk manier verkeerd is wat betreft OO. Komt er iemand door de bocht met "Sinds wanneer is versturen een object?"
Ik kom net tot de conclusie dat ik verkeerd denk, dat jij begrijpt wat er bedoeld word vind ik super. Maar je kunt het ook normaal omschrijven, zoals je wel op je website doet. EN ja ik heb die post op je website gelezen. En waarschijnlijk lees ik het nog 5 keer puur alleen om nu een schakel in mijn hoofd om te zetten.
Op je website zet je neer "artikel" is een object. Vandaar dat ik dacht dat e-mail ook een object is (welke ik boven aanduid met "verstuur" is dat een verkeerde woord keuze van mij. Maar begrijp ik het dan goed als ik jouw pagina gebruik dat e-mail wel een object is?
Erwin H op 27/11/2013 16:59:57
Met je nieuwe gebruiker voorbeeld kan je dus een gebruiker object hebben (met alle kenmerken van de gebruiker), een database object (dat de data in de database toevoegt, of opslaat) en een mailer (dat de mail kan versturen).
En dit is een zeer versimpeld voorbeeld. Alleen je database object zal in het echt al minimaal uit 3 objecten bestaan (database-, connectie- en queryobject), maar al snel nog meer. Bedenk ook dat elk object uiteindelijk maar verantwoordelijk mag zijn voor 1 onderdeel van je applicatie. Je kan dus niet een mailer hebben die ook de content van de emails bepaalt. In dat geval krijg je namelijk al een probleem met het opnieuw gebruiken van dat object, want in een volgende applicatie zijn de mails heel anders.
Even ter illustratie voor mij;
Op plek A heb ik het object "mailer" welke de mail verzend.
Op plek B wil ik een mail versturen.
Op plek B zeg ik wat de mail moet zijn. EN dan verstuur ik door middel van de "mailer" de e-mail. Die dus alleen de e-mail voor mij verzend.
Op plek Z wil ik weer een mail sturen, maar dan met inhoud die anders is. Dan staat op Z mijn content en roep ik A aan?
@Kris Peeters
27/11/2013 17:36:54
Dit heb ik op het moment van posten van dit bericht nog niet gelezen (wel gezien)
--- Reactie op Kris Peeters ---
Zie ik het dan goed dat als ik jouw voorbeeld uitbreid met
$auto->setDeuren(4);
ik waar dan ook in mijn script kan zeggen dat mijn auto 4 deuren heeft (moet dat dan via $auto-setDeuren; ?)
Maar ook als ik dan naar een andere pagina ga?
En geldt het dan ook dat ik bijvoorbeeld ook iets nieuws kan toevoegen wat helemaal niet in het object auto zit? Bijvoorbeeld $auto->setToetsenbord(tekst);?
Het was niet lullig of kort door de bocht bedoelt, R. Mijn excusses als die zo overkwam. Ik denk dat dit een goede conclusie is "welke ik boven aanduid met "verstuur" is dat een verkeerde woord keuze van mij. Maar begrijp ik het dan goed als ik jouw pagina gebruik dat e-mail wel een object is?" De woordkeuze is niet ideaal. "verstuur" is een werkwoord ("versturen"). Object zijn dingen, zelfstandige naamwoorden dus. "kat", "boek", "pen", "huis", ... (je begrijpt het wel :)).
Die werkwoorden zijn de methods (functies) van een object. En om wille van herbruikbaarheid worden deze vaak ook in een klasse gezet. We hebben dan in jouw geval dus een Email object. Deze email wordt verstuurd, een ->send() functie dus. Maar omdat we niet afhankelijk willen zijn van 1 verzend methode (bijv. via de stmp server) plaatsen we deze ook in een object. We hebben nu dus een Email object en een StmpMailer object die die Email verzend.
