[OOP] afhankelijke waardes
echo $user->getFullName();
Deze volledige naam wordt tijdens het laden/initialiseren van de class gegenereerd op basis van de voornaam, tussenvoegsel en achternaam en vervolgens opgeslagen als class property.
Nu vraag ik me iets af. Stel dat ik via een setter de voornaam wijzig van Jantje naar Pietje ...
$user->setFirstName('Pietje');
... en ik zou nu de volledige naam weer ophalen, dan staat daar nog Jantje in. Immers, de volledige naam is niet gewijzigd, enkel de voornaam.
Mijn vraag is hoe je nu met zo'n "afhankelijke" waarde om moet gaan.
Ik denk dat er 2 mogelijkheden zijn:
1) Zodra ik de voornaam, tussenvoegsel of achternaam wijzig ga ik de volledige naam opnieuw genereren en overschrijf ik de bestaande class property.
2) Ik maak niet langer gebruik van een class property om de volledige naam op te slaan. In plaats daarvan genereer ik de volledige naam op basis van de voornaam, tussenvoegsel en achternaam telkens opnieuw als de functie wordt aangeroepen.
Beide opties lijken me mogelijk, maar is een van beiden wellicht logischer?
Alleen als de actie heel "kostbaar" is (database lookup oid) zou ik voor de aanpak van 1 gaan.
Gewijzigd op 22/02/2019 19:33:06 door Rob Doemaarwat
Ik zou gaan voor:
3) Daar het een state change betreft is een page refresh wel op zijn plaats.
Of je moet er even bijvertellen in welke situatie je dit gebruikt waarbij dit voor problemen zorgt.
Zodra je PHP klaar is zijn al deze objecten weg, tenzij je deze op een of andere manier propageert (sessie? database?) in welk geval een andere aanpak waarschijnlijk beter is (elke page access gewoon alles opnieuw uitrekenen).
Gewijzigd op 22/02/2019 19:43:18 door Thomas van den Heuvel
Het gaat dan inderdaad om een relatief simpele concat actie. Het kan natuurlijk zijn dat er geen tussenvoegsel of achternaam is en dan moeten er geen extra spatie worden toegevoegd, dus er komt wel enige "intelligentie" bij kijken, maar het zal niet een hele heftige actie zjin.
@Thomas
In de praktijk zal een naam alleen worden gewijzigd als de gebruiker dat zelf doet. Meestal gaat dat inderdaad gepaard met een page refresh dat klopt, maar het gaat mij meer erom of er richtlijnen zijn voor dit soort situaties waarbij de ene waarde van de andere waarde afhankelijk is.
Ik snap jouw opmerking van een page refresh, maar ik kan me voorstellen dat dit niet altijd aan de orde en/of wenselijk is. Het kan bijvoorbeeld zijn dat in de workflow van de applicatie de User al is ingeladen en dat daarna pas de $_POST gegevens worden opgeslagen in de database waardoor de gegevens in de User class op dat moment niet actueel zijn. De naam Pietje is dan wel opgeslagen in de database, maar op het scherm wordt nog Jantje getoond. Uiteraard kun je dat oplossen met een page reload, maar dan ben je daar dus wel altijd van afhankelijk. Als je dat vergeet, of een andere developer doet het niet, dan krijg je ongewenste resultaten. Ik prefereer daarom een oplossing die in alle gevallen werkt.
Je hebt dus als het ware een waarde A (de volledige naam) die wordt opgebouwd uit X, Y en Z (voornaam, tussenvoegsel, achternaam). De vraag is dus ... als X, Y of Z wijzigt, hoe zorg je dan dat waarde A de juiste waarde geeft.
Daarvoor zijn 2 manieren:
1) Zodra je X, Y of Z wijzigt, genereer je A opnieuw en sla je A op als class property.
2) A wordt altijd 'live' gegenereerd aan de hand van X, Y en Z en wordt nergens opgeslagen.
Wat is van deze 2 de betere optie? Is daar een richtlijn voor.
Toevoeging op 22/02/2019 20:40:54:
Overigens vind ik de uitleg van Rob plausibel, maar het is dus een afweging die hij maakt. En misschien is dat ook gelijk wel de 'stelregel'? Is het een simpele actie, dan 'live' uitvoeren en anders eenmalig uitvoeren en opslaan als class property?? Ik was dus vooral benieuwd of er een richtlijn voor is.
Op de scherm van een andere gebruiker dan wellicht? Van een beheerder? Van een vriend of kennis? Je moet jezelf afvragen of dat echt iets uitmaakt en hoeveel impact dat heeft.
Ik neem aan dat je beseft dat al die objecten slechts milliseconden bestaan tijdens executie van code correct? Daarna zijn ze weer foetsie.
En als je die dus ergens propageert ben je zelf veroorzaker van dit soort "dirty registers" die verouderde waarden bevatten. Als je elke page access de objecten opnieuw uitrekent heb je deze problemen niet of in ieder geval veel minder. Net zoals dat je gebruikersrechten niet opslaat in een sessie eigenlijk. Je creëert op die manier namelijk een heleboel extra (noodzakelijke) administratie.
Het lijkt er trouwens op dat je weer op zoek bent naar een soort van universeel geldende regels voor iets specifieks. Het antwoord op al die vragen is eigenlijk "het hangt er vanaf" :p.
Het voorbeeld hierboven bijvoorbeeld.
#1 is mogelijk een betere strategie als het berekenen van A knetterduur is of lang duurt.
Het hangt er maar vanaf...
Ook dat is een antwoord hè ;-)
Ik had gedacht dat er misschien een soort van richtlijnen voor waren, als in "genereer een variabele die afhankelijk is van andere variabelen altijd real-time". Maar goed, blijkbaar bestaat zoiets dus niet.
>> Op de scherm van een andere gebruiker dan wellicht?
Nee op het scherm van de gebruiker bedoelde ik. Die slaat dan z'n nieuwe naam op. Gegevens worden gepost en in datzelfde request wordt ook een view getoond waarin nog de oude naam staat. Uiteraard is dat allemaal op te lossen, dat is het probleem niet. Maar dit is dus een vraagstuk in algemene zin ... hoe ga je met dergelijke situaties om.
Hoe krijg je dat voor elkaar dan?
Net zoals op deze site? Dat verwerking + tonen door elkaar loopt?
Daar zijn wel ontwerpprincipes voor. Scheid alles in aparte acties. Dan heb je dit probleem helemaal niet.
Dit is ook alleen maar verwarrend naar een gebruiker toe. Je hebt net iets aangepast en er verandert ogenschijnlijks niets (direct) :/.
Soms is het antwoord op je vraag gewoon dat je dingen op een andere plek, en op een andere manier, moet oplossen.
Gewijzigd op 23/02/2019 13:06:15 door Thomas van den Heuvel
Dat was dus een voorbeeldje wat ik gaf. Als je onhandig programmeert en in de afhandeling van de post ook meteen een view toont.
Een iets reëler voorbeeld zou kunnen zijn dat je een post afhandelt en in een log bijhoudt dat je gegevens van Pietje hebt aangepast, die echter inmiddels Jantje heet.
Ik wil over dit soort dingen niet hoeven na te denken en heb liever dat het in alle gevallen werkt. Maar goed, ben er denk ik wel uit hoe ik het ga oplossen, dus komt goed.
Quote:
Ik wil over dit soort dingen niet hoeven na te denken en heb liever dat het in alle gevallen werkt.
Mja, op zich dat je dingen in je achterhoofd analyseert natuurlijk maar ik snap totaal het probleem niet.
- Je hebt een setter: $user->setFirstName('Pietje'); veranderd naar $user->setFirstName('Ozzie');
- Je hebt een getter: echo $user->getFullName();.
Dus in dit geval is het dan toch gewoon een lusje SET, POST, redirect, GET. Meer is het niet.
In zo'n geval heb je toch geen probleem, want het werkt. Wat wil je dan nog meer? Volgens mij is dit al een hele standaard aktie.
Code (php)
1
2
3
4
2
3
4
$user = new \My\User($id); //= "Tijdens het laden van een User class set ik eenmalig de volledige naam"
$user->setFirstName('Ozzie');
//bevestig wijziging
mail($to,$subject,'Beste ' $user->getFullName() . ' ...'); //wordt "Beste Pietje ..." - oeps
$user->setFirstName('Ozzie');
//bevestig wijziging
mail($to,$subject,'Beste ' $user->getFullName() . ' ...'); //wordt "Beste Pietje ..." - oeps
Ondanks SET/POSt/redirect/GET toch een probleem.
Overigens, die setFirstName() zou dan toch ook waarden van klasse-variabelen /-properties moeten bijwerken? Of een interne refresh moeten forceren ofzo. Het zou vreemd zijn wanneer dit gebeurt:
Code (php)
1
2
3
4
2
3
4
$user->setFirstName('Henk');
echo $user->getFullName(); // Henk Whatever
$user->setFirstName('Piet');
echo $user->getFullName(); // Henk Whatever ????????
echo $user->getFullName(); // Henk Whatever
$user->setFirstName('Piet');
echo $user->getFullName(); // Henk Whatever ????????
Dit lijkt mij dan toch echt een tekortkoming in setFirstName(), en niet zozeer een soort van universeel dilemma waarin methoden niet de goede waarden teruggeven... Zorg gewoon dat die waarden uptodate zijn :p (en uit één bron komen).
Daarnaast zijn objecten call by reference, dus het niet alsof je meerdere instanties hebt van "hetzelfde" User object die vervolgens ineens een eigen leven gaan leiden, tenzij je hele rare dingen doet en/of de principes niet snapt of verkeerd toepast.
En dit:
Code (php)
1
//Tijdens het laden van een User class set ik eenmalig de volledige naam
Bleek dan dus bij nader inzien niet zo'n fantastische ontwerpbeslissing.
Gewijzigd op 24/02/2019 16:46:41 door Thomas van den Heuvel
Thomas van den Heuvel op 24/02/2019 16:40:58:
Overigens, die setFirstName() zou dan toch ook waarden van klasse-variabelen /-properties moeten bijwerken? Of een interne refresh moeten forceren ofzo. Het zou vreemd zijn wanneer dit gebeurt:
Dit lijkt mij dan toch echt een tekortkoming in setFirstName ...
Code (php)
1
2
3
4
2
3
4
$user->setFirstName('Henk');
echo $user->getFullName(); // Henk Whatever
$user->setFirstName('Piet');
echo $user->getFullName(); // Henk Whatever ????????
echo $user->getFullName(); // Henk Whatever
$user->setFirstName('Piet');
echo $user->getFullName(); // Henk Whatever ????????
Dit lijkt mij dan toch echt een tekortkoming in setFirstName ...
En daar ging de vraag dus ook precies over ;-)
Rob Doemaarwat op 24/02/2019 17:31:03:
... en dat was de vraag ook: doe ik dan 1 of 2 om het wel goed te doen
Exact!
Met 1) introduceer je zelf allemaal extra administratie omdat je in wezen een kopie trekt van originelen die wellicht onderweg kunnen wijzigen, met 2) genereer je elke keer opnieuw op basis van één rechtstreekse bron een gewenst gecombineerd formaat.
Behoeft dit echt enige uitleg?
Thomas ik stel een vraag niet voor Jan met de korte achternaam. Het genereren van iets kan een wissel op je performance trekken (ik zeg 'kan' ik zeg niet dat het zo is).
Waar ik naar benieuwd was, is of er bepaalde 'technieken' of 'principes' zijn hoe je met zoiets omgaat.
Wat het effect is van bepaalde oplossingen snap ik heel goed.
Jij duidt hierboven oplossing 2 als de beste, maar als dat had betekent dat ik uit 10 databases informatie had moeten verzamelen en 500 queries had moeten afschieten, wat het niet zo'n goede oplossing geweest. Ja Thomas, dat is inderdaad een compleet onzin-scenario, maar ik probeer je duidelijk te maken waarnaar ik op zoek was. Namelijk of er in bepaalde omstandigheden (afhankelijkheid tussen variabelen) bepaalde richtlijnen/technieken/patterns zijn die je kunt volgen.
Volgens mij zien we hier op dit forum om elkaar iets te leren en niet om elkaar de les te nemen ;-)
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Gruwelijk grappig ... dat was de oplossing die ik zelf inmiddels ook had bedacht :-D
Dan heb je inderdaad hele andere problemen/uitdagingen.
Maar wanneer je een triviaal voorbeeld geeft, verwacht dan ook een triviaal antwoord.
Dit is wederom/nog steeds zo'n "het hangt er vanaf" vraag. De oplossing is afgestemd op de problematiek, daar is geen universeel recept voor want de omstandigheden zijn niet universeel.
En als je dan toch zo in vakjes wilt denken verdiep je dan eens in design patterns. Maar zelfs die bieden dus geen concrete oplossingen...
> maar ik probeer je duidelijk te maken waarnaar ik op zoek was
Dit komt niet echt goed uit de verf naar mijn mening. Ik weet niet waar je naar op zoek bent.
> Namelijk of er in bepaalde omstandigheden (afhankelijkheid tussen variabelen) bepaalde richtlijnen/technieken/patterns zijn die je kunt volgen.
Noem eens wat concrete omstandigheden dan. Ik denk dat het aanhouden van één bron en het niet (eindeloos) kopiëren van data je al een heel eind op weg helpt.
Op het moment dat deze data wijzigt (state change) moet er op een of andere manier een refresh worden afgedwongen. Dit bereik je weer makkelijk door in eerste instantie methoden (en pagina's) maar één ding tegelijkertijd te laten doen zodat je dit allemaal kunt compartimenteren. Wanneer je een pagina aanroept dan dient er ook altijd maar één actie tegelijkertijd te worden uitgevoerd. Zo houd je alles netjes gescheiden. Het is een geheel aan maatregelen die je kunt nemen die ervoor zorgen dat alles in goede banen loopt, maar dit is dus een optelsom.
Gewijzigd op 24/02/2019 21:52:54 door Thomas van den Heuvel
Naja, anyhow ... ik dacht dat er wellicht een stelregel was voor dit soort situaties, maar die is er dus klaarblijkelijk niet. Weer iets geleerd in ieder geval.
Net zoals bij een onderzoek is het zaak dat je het onderzoeksgebied afbakent in je probleemstelling. Dit zodat je binnen een duidelijk gedefinieerd domein ook uiteindelijk iets concreets kunt bestuderen en daar dan vervolgens zinnige conclusies aan kunt verbinden.
Yup, maar die zaken gaan wel steeds vaker door elkaar lopen.
Anyhow ... ik kan weer vooruit ;-)