referentie array/object
Wat is het verschil dan?
Jij doet dit:
$request = new Request($cookie, $files, enz.);
En ik stop alles in 1 array:
$request = new Request($request_data);
Wat is precies het verschil? Waarom is het een beter dan het ander?
Ozzie PHP op 30/10/2013 22:44:40:
@Ward: ik hoop dat je nog even een reactie geeft, want ik snap niet wat je bedoelde.
Ik heb wat moeite met twee dingen. Het eerste is het overladen van bestaande variabelen in nieuwe variabelen. Dit voegt niets toe, ongeacht of je een call by name of een call by reference gebruikt:
Code (php)
1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
<?php
// In plaats van dit:
$foo = new Foo($x, $y);
// Doe je dit:
$z = array($x, $y);
$foo = new Foo($z);
?>
// In plaats van dit:
$foo = new Foo($x, $y);
// Doe je dit:
$z = array($x, $y);
$foo = new Foo($z);
?>
Ten tweede gebruik je niet zomaar een array, maar een array met de superglobal arrays zoals $_GET, $_POST en $_COOKIE. Vanwege hun speciale status in een PHP-omgeving horen die, volgens mij, niet allemaal in dezelfde controller te worden gestopt. Dat duidt op een onevenwichtige taakverdeling.
Bovendien hoef je ze niet eens door te geven als object of als array: ze zijn superglobal. In plaats van $form = new Form($_POST) kun je gewoon $form = new Form() gebruiken.
Ze komen ook niet in een controller, maar in een request object.
>> Bovendien hoef je ze niet eens door te geven als object of als array: ze zijn superglobal. In plaats van $form = new Form($_POST) kun je gewoon $form = new Form() gebruiken.
Oeh, dit bedoel je toch hopelijk niet serieus? Ga jij superglobals in je objecten gebruiken? Dan zijn je objecten toch 100% afhankelijk van die superglobals? Je moet ze juist meegeven, dan kun je de klasse gebruiken in welke omgeving het ook is. Ook als er geen POST request is, maar bijv. een GET request. En ook als ik aan het testen ben en er helemaal geen sprake is van superglobals.
Toevoeging op 31/10/2013 07:55:50:
En ozzie, waarom argumenten en geen array? Nou, waarom doe je niet:
Het zijn eigenschappen van het request object die je instelt. Ook kun je met een array geen default options instellen, etc.
@Wouter: ik begrijp je nog steeds niet helemaal.
a) In jouw voorbeeld met de user gebruik je zelf toch ook een array?
b) ik heb in dit geval geen defaults nodig omdat het om de superglobals gaat. Als die niet gevuld zijn (omdat er niks is gepost) dan wordt het automatisch een lege array.
En waarom ik alles in 1 array stop is omdat ik die informatie moet doorgeven aan een paar verschillende classes. Waarom zou ik dan telkens 5 variabelen (cookie, files, get, post, server) gaan doorgeven en ook telkens 5 class properties gaan setten, terwijl ik alles gewoon in 1 array $globals kan stoppen?
Ik begrijp dat je me iets duidelijk wil maken, alleen ik snap niet wat je nu precies bedoelt. Ik hoop dat je het nog even kunt toelichten.
Gewijzigd op 31/10/2013 13:06:49 door Ozzie PHP
Als ik de reactie van Wouter lees dan is dit de taak van de request object? Hoe ziet een simpele request object er uit dan? en ga je die daarna injecteren in de classes die hem nodig hebben?
Het tweede argument van Wouter daar kunnen we het allemaal wel mee eens zijn lijkt me. Hoe flexibeler je code is hoe beter.
De data uit de superglobals geef je via de constructor aan het request object mee. Het request object stop je in je service container. En inderdaad, het request object injecteer je in je classes/services die het nodig hebben.
>> Het tweede argument van Wouter daar kunnen we het allemaal wel mee eens zijn lijkt me. Hoe flexibeler je code is hoe beter.
Alleen begrijp ik dus niet wat Wouter bedoelt. Hij zegt dat je geen array moet gebruiken, maar doet dat zelf in zijn voorbeeld wel. En zie ook mijn opmerking hierboven waarom ik alles in 1 array stop. Dat lijkt me toch juist handig in dit specifieke geval? Ik ben dus benieuwd waarom dat (volgens Wouter) niet zo is.
Dus jij ziet dat als een best practise? Werk je dus nooit met meerdere argumenten, maar gebruik je slechts een array?
Ik hoopte dat ik duidelijk genoeg was dat het voorbeeldje van de User een manier is die je niet moet toepassen.
> En waarom ik alles in 1 array stop is omdat ik die informatie moet doorgeven aan een paar verschillende classes. Waarom zou ik dan telkens 5 variabelen (cookie, files, get, post, server) gaan doorgeven en ook telkens 5 class properties gaan setten, terwijl ik alles gewoon in 1 array $globals kan stoppen?
Als het goed is heeft alleen het Request object te maken met die globals.
Nee, zeker niet. Maar dat wil niet zeggen dat het in sommige gevallen niet kan.
>> Als het goed is heeft alleen het Request object te maken met die globals.
Uiteindelijk wel, maar ik geef ze door via de kernel. Jij maakt eerst een request object en die stop je in je kernel. Ik stop de request data in de kernel en de kernel maakt een request object. Iets andere benadering dus.
En daarnaast, als je zograag in de kernel een request object aanmaakt zou ik het gewoon in 1 keer met super globals in de kernel stoppen. De kernel is toch afhankelijk van het request geworden
Ik vind het persoonlijk mooier en handiger, omdat de kernel/processor nu alles regelt. Ik stop de globale data in de kernel en die regelt vervolgens de rest. Eigenlijk doen we bijna hetzelfde. Jij geeft een object mee aan de kernel, maar ik geef de ruwe data mee. Dus op zich is er niet heel veel verschil. Jouw methode vind ik ook zeker niet verkeerd.
>> En daarnaast, als je zograag in de kernel een request object aanmaakt zou ik het gewoon in 1 keer met super globals in de kernel stoppen. De kernel is toch afhankelijk van het request geworden
Euh ja, maar dit is dan weer "jouw" methode? Of begrijp ik je nu verkeerd?
Ozzie PHP op 31/10/2013 20:14:04:
>> En waarom doe je die methode van jouw dan? Wat is daar het voordeel van?
Onafhankelijkheid
Wouter gaat weleens wat snel voor ons maar als je goed naar zijn argumenten kijkt dan weet je waarom hij eerst een request object maakt. Onafhankelijkheid. Zijn code is dus in diverse gevallen (her)bruikbaar.
Overigens dacht ik ook dat Wouter het meende met die "User" array. begreep het al niet helemaal LOL
Gewijzigd op 01/11/2013 00:40:30 door Frank Nietbelangrijk
Wat wouter doet is dit:
$request = new Request ($_COOKIE, $_FILES, enz.);
$kernel = new Kernel($request);
en wat ik doe:
$kernel = new Kernel($_COOKIE, $_FILES, enz.);
We geven dus allebei van buitenaf de request-data door aan de kernel. We doen volgens mij precies hetzelfde. Alleen ik maak het request-object aan in de kernel, en Wouter erbuiten. Maar we gebruiken precies dezelfde data. Ik vind het mooier om het request-object door de kernel class te laten maken zodat je geen extra "handelingen" hoeft te doen voordat je de kernel class aanroept. Het enige wat je hoeft te doen is de request-data in de kernel gooien, en de kernel regelt de rest. Dus nu ben ik benieuwd waarom Wouter's versie volgens jou onafhankelijker is dan de mijne.
Gewijzigd op 01/11/2013 00:47:35 door Ozzie PHP