Tijdens het laden van een User class set ik eenmalig de volledige naam van de User zodat ik deze als volgt kan tonen.

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?
... en dat was de vraag ook: doe ik dan 1 of 2 om het wel goed te doen
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:
$user->setFirstName('Henk');
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!
Ah.

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?
>> 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 ;-)
Zelf zit daar m'n grens zo'n beetje: moet ik in de getter de database of een file raadplegen, dan ga ik 'm opslaan. Ik doe dat dan meestal zo:
<?php
class Foo{

  protected $_bar = null;

  public function getBar(){
    if($this->_bar === null){
      $this->_bar = "whatever"; //als het maar geen null is, dan expliciet false maken ofzo
    }

    return $this->_bar;
  }

  public function ietsAndersWatBarBeinvloed(){
    $this->_bar = null;
    //doe ding
  }

}

?>
@Rob,

Gruwelijk grappig ... dat was de oplossing die ik zelf inmiddels ook had bedacht :-D
> 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.
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.
Ik snap wel wat je bedoelt hoor, maar mijn vraag was in algemene zin hoe je met een bepaald probleem omgaat. Eén actie per pagina-aanroep is nu iets wat jij noemt en vroeger was dat normaal. Maar tegenwoordig is er bijvoorbeeld ajax. Zo zullen er bijv. best websites zijn die een formulier/datawijziging via ajax laten verlopen. Dan wijzig je je naam naar iets anders, maar de rest van de pagina wijzigt niet.

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.
Euh, het klassieke schaakspel van HTTP (request-response) is natuurlijk iets compleet anders dan een AJAX-driven applicatie...

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.
>> Euh, het klassieke schaakspel van HTTP (request-response) is natuurlijk iets compleet anders dan een AJAX-driven applicatie...

Yup, maar die zaken gaan wel steeds vaker door elkaar lopen.

Anyhow ... ik kan weer vooruit ;-)

Reageren