service container vraag
Ozzie PHP op 01/04/2013 17:38:31:
Uhm... oke... maar dat is nu dus hoe ik het doe...
Ik heb in een class een andere class nodig... en ik geef die class dan mee via de service container. Ik bepaal zelf welke class ik meegeef (door de naam van de class). Ik zou eerlijk gezegd niet weten wat ik voor extra intelligentie zou moeten inbouwen, en hoe...
Ik heb in een class een andere class nodig... en ik geef die class dan mee via de service container. Ik bepaal zelf welke class ik meegeef (door de naam van de class). Ik zou eerlijk gezegd niet weten wat ik voor extra intelligentie zou moeten inbouwen, en hoe...
Praktijk voorbeeld. In mijn framework heb ik de mogelijkheid ingebouwd om runtime te bepalen welk output taal gebruikt moeten worden (lees: HTML4 of HTML5). Dit wordt niet door de classes bepaald die een object nodig hebben dat output kan genereren, maar in feite door de browser versie. Het aanvragende object zal dus nooit tegen de service container zeggen geef me een HTML4 object. Die vraagt alleen om een object dat bijvoorbeeld een tabel kan bouwen. De service container zal dan ergens anders vandaan halen dat hij nu dat HTML4 object moet geven, maar bij de volgende aanvraag een HTML5 object.
Ozzie PHP op 01/04/2013 17:38:31:
Maar stel nu... ff heel stom voorbeeldje he, maar t gaat even om het idee ;)
Stel nu... er zijn geen schroeven aanwezig om de motor vast te zetten. Dan hebben we dus ook geen motor nodig, en had er dus ook geen motor object hoeven te worden aangemaakt.
Hoe kun je bovengenoemde situatie voorkomen? Stel dat je pas in de Auto class zelf weet of er schroeven zijn? Zo ja, dan heb je de motor nodig, zo nee dan heb je de motor niet nodig. Echter, omdat je de motor meegeeft in de constructor heb je altijd een motor, ongeacht of er schroeven zijn. Kun je in zo'n geval voorkomen dat het motor object wordt aangemaakt?
Stel nu... er zijn geen schroeven aanwezig om de motor vast te zetten. Dan hebben we dus ook geen motor nodig, en had er dus ook geen motor object hoeven te worden aangemaakt.
Hoe kun je bovengenoemde situatie voorkomen? Stel dat je pas in de Auto class zelf weet of er schroeven zijn? Zo ja, dan heb je de motor nodig, zo nee dan heb je de motor niet nodig. Echter, omdat je de motor meegeeft in de constructor heb je altijd een motor, ongeacht of er schroeven zijn. Kun je in zo'n geval voorkomen dat het motor object wordt aangemaakt?
Dan doe je iets fout. Ofwel je moet de motor niet meegeven in de constructor, ofwel je moet de schroeven OOK meegeven in de constructor, ofwel het object dat de auto aanmaakt moet inzien dat de auto niet aangemaakt kan worden.
Toevoeging op 01/04/2013 18:00:52:
Ward van der Put op 01/04/2013 17:44:37:
Als er een betere en veiligere versie van een klasse is, zou díé de baas moeten zijn. Daarom vind ik het fundamenteel verkeerd om een service container op te voeren die kan zeggen: "Schijt aan alle verbeteringen en beveiligingen; ik laad doodleuk de versie die in het laatste configuratiebestand staat."
In feite zeg je dus dat de laatste versie die bestaat de baas is. Maar ik zie niet het verschil met dat opgeven in de bestandsnaam/directory/namespace (want op basis daarvan zal de autoloader neem ik aan zien dat er een nieuwere versie is), of dat opgeven in een configuratiebestand zodat de service container dat mee kan geven in de naam van de class die hij aanvraagt.
Wat is voor jou het verschil?
Ah ja, oké... dit snap ik. Wat je wil zeggen is (denk ik) dit. Dat je soms niet weet welke class moet worden meegegeven en dat je die niet hardcoded (vanuit een configuratiebestand) moet meegeven in de service container, maar runtime moet toevoegen aan de container. Dus een database service zet je er niet hardcoded in, maar voeg je runtime toe, afhankelijk van of je bijv. wel of niet in test-modus zit. Correct?
Dat met die schroeven snap ik, maar neem het voorbeeld van de session wat ik op de vorige pagina noemde. Je weet pas in het requests object of er een sessie is gestart. Op basis daarvan moet er wel of niet een class worden aangemaakt. Hoe los je zo'n situatie dan op?
Stel we hebben een request class. In die request class wil ik de data uit de sessie opslaan. Echter, er is niet altijd sprake van een sessie, bijvoorbeeld omdat men niet is ingelogd.
Zoals ik al zei wil ik de gegevens uit de sessie opslaan in een eigen class, en deze class wil ik opslaan in een class property van het request object. Schematisch moet er in de request class dus dit gebeuren:
Code (php)
1
2
3
4
5
2
3
4
5
if (sessie is gestart) {
$this->session_data = new Session_Data($_SESSION);
} else {
$this->session_data = null;
}
$this->session_data = new Session_Data($_SESSION);
} else {
$this->session_data = null;
}
Echter, nu maak ik hardcoded een nieuwe class aan in het request object, en dat willen we niet. Dus mijn vraag is... hoe los je zo'n situatie op. Stel dat ik de service container als argument zou meegeven aan de request class, dan zou ik het zo kunnen doen:
Code (php)
1
2
3
4
5
6
2
3
4
5
6
if (sessie is gestart) {
$session_data = $this->container->get('session_data);
$this->session_data = $session_data->set($_SESSION);
} else {
$this->session_data = null;
}
$session_data = $this->container->get('session_data);
$this->session_data = $session_data->set($_SESSION);
} else {
$this->session_data = null;
}
Of weet jij nog een andere/betere manier?