Even geleden heb ik het met jullie gehad over de invulling van een User class. Nu heb ik daar toch nog een vraag over.
In de praktijk zul je van veel users hun tel.nr. willen weten. Bijvoorbeeld van klanten die iets bestellen, of van de administrators die de website beheren. Aan deze personen is het heel logisch om hun tel.nr. te vragen.
Oké denk ik dan. Als ik aan veel users hun tel.nr. wil vragen dan lijkt het me dus handig om in de User class een set/getPhoneNumber method op te nemen. Toch?
Echter... en daar gaat mijn vraag over... er zijn ook situaties waarin je aan een user niet zijn/haar tel.nr. zal vragen. Bijvoorbeeld aan mensen die zich inschrijven op een forum (zoals bijv. dit forum). Toch heb je dan wel een set/getPhoneNumber method in de User class staan. Is dat een gebruikelijke situatie?
Ten eerste ozzie, Die bluetooth op jou telefoon dat zit erin omdat ze ervoor kiezen om een telefoon uit te rusten met bluetooth, internet module, etc etc en alle andere mikmak wat op jou telefoontje zit. Er zit niet STANDAARD in elke telefoon een bluetooth chip/zender.
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.
Ozzie, Ik ga je vraag niet beantwoorden maar ik ga jou een vraag stellen. Waarom wil je wel email erin en niet naam of user_id of user_age of user_geslacht? zo kan ik door blijven gaan tot ik eindeloos veel dingen heb die er zeker wel in kunnen maar die ik dus misschien helemaal niet nodig zal hebben. Ja oké email kan je misschien vaker nodig hebben dan user_geslacht maar dat betekent niet dat je de ene wel vooraf op de plank moet leggen en de andere niet. je moet gewoon accepteren dat een user klasse geen generieke klasse is en dat je deze gewoon moet bouwen wanneer je de use-case model eerst hebt gemaakt en dus weet wat de functionaliteit van je applicatie wordt. Op basis hiervan ga je dan een user klasse maken die je gaat gebruiken.
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 wat je bedoelt Reshad. Ik heb er natuurlijk ook over nagedacht met het oog op wat ik er mee wil doen. Ik ben het met je eens dat het niet zinvol/mogelijk is om alles in 1 generieke class te verpakken. Het idee was dan ook om er enkel een paar basis-dingen in te stoppen.
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?
Daar is niks ergs aan maar dan ben je dus niet consistent en dat is weer wel erg want zoals ik al zei een email is niet enkel het enige wat generiek in een user class thuis zou horen als je helemaal door gaat denken.
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.
>> 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.
