Do $ _POST, $ _GET, etc violano il principio di incapsulamento?

Non sono del tutto sicuro del motivo per cui si applica json_decode a $_GET a "convertirlo in un array"; $_GET già è un array.

Usando i super-globals ( $_GET , $_POST etc) è una violazione del principio di incapsulamento. Ma c'è stata una linea disegnata dove smetti di incapsulare le cose. La richiesta di dati è un buon candidato per l'incapsulamento, ma non fatevi ingannare dal tentativo di incapsula tutte le cose .

La maggior parte dei framework di solito avvolge i super-globals di PHP in una qualche forma di oggetto di richiesta. Facendo questo, è più facile prendere in giro i test, ecc. L'approccio più semplice sarebbe:

<?php
class Request
{
    public $get;
    public $post;
    public $session;
    public $cookie;

    public function __construct($get, $post, $session, $cookie)
    {
        $this->get = $get;
        $this->post = $post;
        $this->session = $session;
        $this->cookie = $cookie;
    }
}

$request = new Request($_GET, $_POST, $_SESSION, $_COOKIE);

È semplice e rudimentale, ma fa il lavoro. È anche consigliabile filtrare i dati a questo punto, per difendersi dalle iniezioni di XSS.

Ma è racchiuso in un oggetto Request . L'oggetto Request ha quattro matrici e questi array possono essere facilmente derisi:

$get = array(
    'foo' => 'bar'
);
$post = array();
$session = array(
    'user' => 1
);
$cookie = array();

$request = new Request($get, $post, $session, $cookie);

L'uso di superglobali $_{POST,GET,SERVER} o qualsiasi altra cosa viola l'incapsulamento.

Questo problema aumenta quando si desidera creare "richieste locali" all'interno del lato server dell'applicazione come molti framework fanno oggigiorno.

Non sono abituato a lavorare con frameworkds, ma quello che faccio di solito è creare una coppia di richiesta / risposta all'inizio del mio processo. La richiesta contiene i valori di questi parametri globali.

Se voglio creare un subrequest lato server, ho due opzioni: usare il contesto corrente o crearne uno completamente nuovo. Quindi, penso che non dovresti disabilitare queste variabili superglobali perché FORSE vorresti usarle di nuovo. Inoltre, per questo motivo, non sono d'accordo sul fatto che i parametri di richiesta dovrebbero essere singleton.

Contenendo solo valori, non riferimenti a questi superglobali, una modifica in un oggetto Request non influirà mai su un altro, quindi il problema con lo stato globale è risolto.

Quindi, in sostanza, ho due opzioni:

// Using global context
$request = new Request(array(
    'post' => $_POST,
    'get' => $_GET
));

// or creating a new context

$request = new Request(array(
    'post' => ['someKey' => 'someValue'],
    'get' => ['queryParam' => 'queryValue'],
));

POST- e GET-vars sono inviati al server in un'unica soluzione e php deve capirli. In un certo senso, ha senso averli disponibili a livello globale, così lo sviluppatore può scegliere dove elaborarli.

Molti framework (come CakePHP per esempio) leggono i Parametri e li posizionano tutti in una matrice, oggetto o struttura simile. Dopodiché, vengono gestiti come qualsiasi altro dato e vengono passati a tutti i metodi che li richiedono.

L'incapsulamento è un buon principio quando c'è la possibilità che tu possa aver bisogno di più istanze di qualcosa. Ma c'è solo un set di parametri per una pagina web. Se fossero in una classe invece di variabili globali, probabilmente sarebbero dei singleton. Non c'è alcun miglioramento significativo passando dalle variabili globali alle classi Singleton, è solo una sintassi diversa per accedervi. Sono ancora oggetti intrinsecamente globali, è solo più ingombrante perché devi gestire l'istanza della classe e passarla in giro.

Dato che questi parametri sono accessibili così frequentemente, i progettisti di PHP hanno deciso di renderli facilmente accessibili, piuttosto che aderire a rigidi principi di progettazione. È una buona idea rendere convenienti le operazioni più comuni, altrimenti i programmatori ti malediranno per averle ripetute ogni volta la stessa cosa lunga.