[oop] wel of niet optionele method?
Maar een generic user classe blijft gewoon een slecht idee. Niet doen.
Ik vind het tof dat je me probeert te overtuigen en dat waardeer ik ook zeker. Maar jij zegt nu alleen "niet doen" en ik weet niet waarom niet.
Ik geef aan dat iedere User een e-mailadres moet hebben. Vervolgens vraagt Wouter aan mij waarom iedere User een mailadres zou moeten hebben. Vervolgens zeg ik dat iedere User een mailadres moet hebben (hoe wil je je anders aanmelden en je aanmelding verifiëren). Dan zeg jij dat ik koppig ben en dat het "een slecht idee is".
Laten we naar de praktijk kijken, en niet naar de theorie. Heb jij je ooit bij een website aangemeld zonder je e-mailadres op te geven? Of ken jij een site waar je je kunt aanmelden zonder je e-mailadres op te geven? Ik niet. Jij zegt "Daar gaat het er nu even niet om." maar dan vraag ik me af waarom het daar niet om gaat, en waar het volgens jou dan wel over gaat. Je wil toch een website bouwen die op de praktijk is gericht? Stel dat je bij 1 op de 1.000 websites geen mailadres nodig zou hebben, zou dat voor jou dan een reden zijn om die functionaliteit dan maar niet in te bouwen? Dat lijkt mij dus niet handig. Ik vind het juist handig dat als ik ergens een User nodig heb, ik al een "standaard" User class op de plank heb liggen waar ik hooguit nog een paar kleine dingen aan toe hoef te voegen.
Maar goed... je bent van harte welkom om mijn mening te weerleggen, maar geef me dan alsjeblieft wel argumenten of een code-voorbeeld. Met "gewoon een slecht idee" kan ik niks. Dat helpt mij niet verder. Dus nogmaals. Ik waardeer dat je meedenkt, alleen op dit moment kan ik er nog niet zoveel mee.
Dat ooit een email opgegeven moet zijn om in te kunnen loggen op example.com betekend niet dat de forum module's User class het nodig heeft.
Gewijzigd op 21/04/2014 22:15:04 door Dos Moonen
>> Laten we naar de praktijk kijken, en niet naar de theorie. Heb jij je ooit bij een website aangemeld zonder je e-mailadres op te geven? Of ken jij een site waar je je kunt aanmelden zonder je e-mailadres op te geven? Ik niet. Jij zegt "Daar gaat het er nu even niet om." maar dan vraag ik me af waarom het daar niet om gaat, en waar het volgens jou dan wel over gaat. Je wil toch een website bouwen die op de praktijk is gericht?
Leer nu eens je code afscheidelijk houden van de praktijk. Je wilt een GENERIEKE user klasse, GENERIEK is iets wat buiten de praktijk blijft. Voor een normale user klasse kan je kijken naar de praktijk. Een user heeft in de praktijk een username en password, email adres en dergelijke nodig. Een GENERIEKE user heeft dan bijvoorbeeld enkel een username en wachtwoord nodig. Maar misschien ook niet? Als je je code abstract genoeg maakt kan je het zelfs maken dat een user als een guest geld. Dan valt heel je idee van een "generieke" user al direct weg.
Laten we nu eens goed nadenken. OO-code moet goed en netjes werken in elke situatie. Je wilt een generieke user klasse. Houd de term "generiek" goed in je achterhoofd. Stel we maken een site die geen e-mail nodig heeft. Enkel usernaam en wachtwoord. Woeps! Die generieke user class is dan plots niet meer zo generiek. Wat ik probeer duidelijk te maken is dat je misschien wel geen e-mail adres nodig hebt. Of misschien wel. Dat is niet generiek meer. Snap je?
Dus, hebben we die wel nodig, dan is de programmeur zo vrij om een email field bij te voegen aan de user (= want een e-mail adres hebben we in die specifieke use case nodig).
Als je nog steeds niet snapt wat ik probeer duidelijk te maken: lees dan deze post 5x opnieuw. Of misschien wel 10x.
Als ik jouw stelling even versimpeld vertaal, dan zeg jij dit:
- bouw geen e-mail functie in, want het kan een keer voorkomen dat je die niet gebruikt.
Als ik mijn stelling even versimpeld vertaal, dan zeg ik:
- bouw een e-mailfunctie in, want die heb je in 98% van de gevallen nodig.
Ben je het tot zover met me eens?
Nu is dus de vervolg-vraag: wat is wijsheid?
Als we uitgaan van jouw situatie, is een User class in feite leeg. Niks staat vast, dus we kunnen ook geen User class maken. We gaan per project kijken wat we nodig hebben, en we maken per project een User class. Stel dat we 100 projecten maken, dan gaan we dus 100x een User class maken. Het voordeel is dat de User class op maat is, het nadeel is dat we 100 nieuwe User classes moeten maken, waarvan er 98 hetzelfde zijn.
Gaan we uit van mijn situatie, dan gebruiken we telkens dezelfde User class waar al wat basis-functionaliteit (e-mailadres) inzit. Ik hoef dus niet 100x een nieuwe User class te maken, maar ik pak de bestaande User class zo uit de library. In 98 gevallen is deze User class correct. In 2 gevallen bevat de User class e-mail functionaliteit die overbodig is en niet wordt gebruikt.
Dit is even een versimpelde versie van onze beide standpunten. Nu is de vraag wat wenselijk is. In mijn optiek (Wij van WC-EEND...) is mijn aanpak efficiënter dan die van jou. Uiteraard ben ik benieuwd naar jouw tegenargumenten waarom jouw oplossing beter is.
Dat weet ik niet.
>> Als we uitgaan van jouw situatie, is een User class in feite leeg. Niks staat vast, dus we kunnen ook geen User class maken.
Nee, een GENERIEKE user class is leeg, geen gewone.
>> Stel dat we 100 projecten maken, dan gaan we dus 100x een User class maken. Het voordeel is dat de User class op maat is, het nadeel is dat we 100 nieuwe User classes moeten maken, waarvan er 98 hetzelfde zijn.
Nu moet je 'ns logisch nadenken. Je gaat geen 100 projecten maken. Bij OOP moet je niet altijd kijken wat efficiënt is, maar wat wanselijk is voor je project.
En hier stopt het voor mij. Als je zo overtuigt bent van je idee, doe het, en je zult vanzelf zien dat je het verkeerd aanpakt.
Wie zegt dat? :-s
Ik vind het jammer dat je het telkens opgeeft. Je zegt nu al een paar keer dat het hier voor jou stopt. Echter, ik hoor van jou geen WAAROM.
Als je dat nu eens uitlegt, dan kan ik er iets mee. Wat is er niet goed aan mijn idee, en wat is er wel goed aan jouw idee? Dat is alles wat ik je vraag.
Wat is er fout aan dat wanneer je weet dat je in vrijwel alle gevallen iets nodig hebt, je deze functionaliteit standaard inbouwt, en accepteert dat deze een enkele keer overbodig is?
Mijn telefoon heeft ingebouwd bluetooth. Ik zal je vertellen... ik gebruik het (vrijwel) nooit! Maar als je het nodig hebt dan is het er wel en hoef ik niet gelijk een andere telefoon te kopen. Nu is bluetooth iets wat ik bijna niet gebruik. Maar die e-mail functionaliteit is dat juist wel. Waarom niet inbouwen, en accepteren dat het een enkele keer niet wordt gebruikt. Wat is daar het nadeel van?
Gewijzigd op 21/04/2014 23:30:39 door Ozzie PHP
Lees dan dit bericht een paar 1000 keer door als je nog steeds niet weet waarom:
http://www.phphulp.nl/php/forum/topic/oop-wel-of-niet-optionele-method/94628/2/#678980
Toevoeging op 21/04/2014 23:35:53:
>> Mijn telefoon heeft ingebouwd bluetooth. Ik zal je vertellen... ik gebruik het (vrijwel) nooit! Maar als je het nodig hebt dan is het er wel en hoef ik niet gelijk een andere telefoon te kopen. Nu is bluetooth iets wat ik bijna niet gebruik. Maar die e-mail functionaliteit is dat juist wel. Waarom niet inbouwen, en accepteren dat het een enkele keer niet wordt gebruikt. Wat is daar het nadeel van?
Object georiënteerd denken en applicaties maken != onzin als dat
Mocht iemand anders nog iets willen toevoegen of verduidelijken, dan hoor ik het graag.
Ozzie, jou user class voor project X heeft een email adres omdat jij ervoor gekozen hebt om een email adres te gebruiken als credential. Ik ben op het moment bezig met een applicatie waarbij ik wel een user object nodig heb maar dit regel via een service account als FB, Google, Twitter etc. En ik hoef de gebruiker geen mail te sturen want dat is helemaal niet nodig voor dit project alles gaat op basis van de vooraf geverifieerde informatie uit de FB, Google, Twitter api.
Conclusie, Jou email zit ingebakken in jou user class omdat je deze wilt gebruiken voor bepaalde functionaliteit. Mijn user class heeft dit niet omdat ik hier geen gebruik van wil maken. Ja natuurlijk kan ik hem er wel inzetten omdat ik hem de andere 99 keren wel gebruik maar dan kan ik er zo 2000 functies bijzetten die ik ook 99 van de 100x bij andere projecten "misschien" ga gebruiken.
Mijn tip naar jou is stop met programmeren. Koop een software ontwikkel methodiek boek voor bijvoorbeeld RUP of SCRUM en ga volgens het boekje tewerk. Wanneer jij alle benodigde documentatie op orde hebt dan weet jij zelf welke functionaliteit er precies in de applicatie moet komen, welke domeinmodel je hebt welke implementatie model je hebt welke use-cases je hebt etc etc.. en het enige wat je dan nog rest om te doen is start je computertje op de nodige classes aanmaken en de functionaliteit ervan inbouwen.
Alles wat je daarna NIET nodig hebt om de functionaliteit tot stand te brengen laat je bij desbetreffende project achterwege. Het kan best zijn dat jij dus een user class krijgt die alleen een naam teruggeeft/invoegt en verder niks.
Ik ben dus van plan om bij alle projecten die ik voor ogen heb gebruik te maken van e-mail. Ik ben absoluut NIET van plan om er 2000 "mogelijk" opties bij te zetten. Maar die e-mail is iets waar ik heel zeker van ben. Dat is dus de reden dat het mij handig lijkt om die er standaard in te bouwen.
Tuurlijk, zeg nooit nooit, het zou van de 100 keer 2 keer kunnen voorkomen dat ik 'm niet nodig heb. Dan gebruik ik het dus ook niet.
Ik wil dus graag weten waarom dit volgens jou fout is:
- 1 User class bouwen, accepteren dat in 2 gevallen de mail functionaliteit "overbodig" is
en waarom dit volgens jou beter is:
- 100 User classes bouwen, waarvan er 98 hetzelfde zijn en de overige 2 ook.
Kun jij deze ene vraag beantwoorden? Misschien dat ik het dan namelijk begrijp.
Daarom herhaal ik nog een keer. Ga terug naar de tekentafel bij aanvang van een project en werk alle documentatie uit zoals de use-case model, use-case beschrijvingen, implementatie model plan van aanpak eventueel etc etc..
dus ga geen praktijkvoorbeeld bedenken voor je applicatie maar ga alles vastleggen en bouw aan de hand van je documentatie niet aan de hand van mogelijkheden.
Ik snap jouw uitleg dus wel, maar ik ben wel nog steeds benieuwd naar het antwoord op mijn vraag:
Stel ik heb dus een User class waar de e-mail functionaliteit al in zit. Maar in een enkel project gebruik ik deze functionaliteit niet. Wat is daar dan precies erg aan?
Verder denk ik dat je nu zelfs op een heel verkeerd niveau zit want je zou niet eens die user class standaard in je framework moeten hebben enkel een aantal klassen in je vendor directory om, wanneer jij een user class nodig hebt, een user class te maken.
Wat bedoel je hiermee? Kun je een voorbeeld geven?
Of je wel of niet een User class in je library wil, is een persoonlijke keuze lijkt me. Stel ik weet bijv. dat ik veel projecten ga doen, waarbij de user een klant/afnemer is. Dan kun je in je library toch al een default member/consumer aanmaken? Iedere keer dat je in een project dan een klant nodig hebt, ligt je user al op de plank.