Using globals makes your code hard to test thus more prone to bugs, not secure and unpredictable. That’s why we pass the variables we want inside a function/object. So my question is simple:
Do $_POST, $_GET, etc violate the encapsulation principle?
I’m thinking that, to retain control of those variables in an OO way, an ideal solution would be to add some lines like this to the code:
// Convert the $_GET array to an object
$get = json_decode(json_encode($_GET), FALSE); // stackoverflow.com/a/1869147
// Stop it from being included from anywhere
unset($_GET);
// Small example of what could be done later on
$DB = new PDO(/* ... */);
$Person = new Person($DB, $get->id);
I haven’t seen this anywhere, not even a tutorial nor recommendation. Also, we can clearly see how the code above is much easier to be tested than one that includes $Person = new Person($DB, $_GET['id']); or even (the ugly) $Person = new Person($DB); as you can use a mock $get object.
Is the code above in the right direction or am I missing something?
EDIT: After some investigation (Zend framework and Cake PHP) as Alexander Kuzmin suggested, it seems to be the right thing to go. They’re probably too big for me to dig into the code ATM, but I’ll keep it in mind.
9
I’m not quite sure why you apply json_decode to $_GET to “convert it to an a array”; $_GET already is an array.
Using the super-globals ($_GET, $_POST etc) is a violation of the encapsulation principle. But there has been to be a line drawn where you stop encapsulating things. Request data is a good candidate for encapsulation, but don’t get sucked down the rabbit hole of trying to encapsulate all the things.
Most frameworks usually wrap PHP’s super-globals into some form of request object. Doing this then makes it easier to mock for tests etc. The simplest approach would be:
<?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);
It’s simple and rudimentary, but does the job. It’s also advisable to filter the data at this point, to defend against XSS injections.
But it’s wrapped in a Request object. The Request object has four arrays, and these arrays can easily be mocked:
$get = array(
'foo' => 'bar'
);
$post = array();
$session = array(
'user' => 1
);
$cookie = array();
$request = new Request($get, $post, $session, $cookie);
6
Using superglobals $_{POST,GET,SERVER} or whatever surely violates the encapsulation.
This problem grows when you want do create “local requests” within the server side of you application as many frameworks do nowadays.
I’m not used to work with frameworkds, but what I usually do is to create a Request/Response pair at the beginning of my processing. The request contains the values these global parameters.
If I want to create a server-side subrequest, I have two options: use the current context or create a entirely new one. So, I think you shouldn’t unset these superglobal variables because MAYBE you’d want do use them again. Also, for this reason, I disagree that request params should be singletons.
By containing only values, not references to these superglobals, a change in one Request object will never affect another, so, the problem with global state is solved.
So, basically, I have two options:
// 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- and GET-vars are sent to the server in one bulk and php has to make sense of them. In a way, it makes sense to have them available globally, so the developer can choose where to process them.
Many frameworks (like CakePHP for example) read the Parameters and then place them all in some array, object or similar structure. After that, they are handled like any other data and are passed to all methods needing them.
2
Encapsulation is a good principle when there’s a chance that you might need multiple instances of something. But there’s only one set of parameters to a web page. If they were in a class instead of global variables, they would probably be singletons. There’s no significant improvement going from global variables to singleton classes, it’s just a different syntax to access them. They’re still inherently global objects, it’s just more cumbersome because you have to get a handle on the class instance and pass it around.
Since these parameters are accessed so frequently, the PHP designers made a decision to make them easy to access, rather than adhere to rigid design principles. It’s a good idea to make the most common operations convenient, otherwise programmers will curse you for making them retype the same, long thing every time.
3