Common Questions

Sometimes we will find that a static class method uses a global variable like so:

1 <?php
2 class Foo
3 {
4 static public function doSomething($baz)
5 {
6 global $bar;
7 // ... do something with $bar ...
8 }
9 }
10 ?>

This is a problem because there is no constructor to which we can move the global variable as a property. There are two options here.

The first option is to pass all the needed globals as parameters on the static method itself, thereby changing the signature of the method:

1 <?php
2 class Foo
3 {
4 static public function doSomething($bar, $baz)
5 {
6 // ... do something with $bar ...
7 }
8 }
9 ?>

We would then search the codebase for all uses of Foo::doSomething( and pass the $bar value each time. For that reason, I suggest adding the new parameters to the beginning of the signature, rather than to the end, because it makes search-and-replace much easier. For example:

Search for:

Foo::doSomething\(

Replace with:

Foo::doSomething\($bar,

The second option is to change the class so that it must be instantiated, and make all the methods instance methods. The class, after conversion, might look like this:

1 <?php
2 class Foo
3 {
4 protected $bar;
5
6 public function __construct($bar)
7 {
8 $this->bar = $bar;
9 }
10
11 public function doSomething($baz)
12 {
13 // ... do something with $this->bar ...
14 }
15 }
16 ?>

After that, we would need to:

  1. Search the codebase for all Foo:: static calls;
  2. Create instances of Foo with its $bar dependency (e.g., $foo = new Foo($bar);) before those static calls are made, and
  3. Replace calls of Foo::doSomething() with $foo->doSomething().

The process described above is a class-by-class process, where we first move the globals in a single class to the constructor, then change from global properties to instance properties in that class, and finally change instantiations of that class.

Alternatively, we might choose a modified process:

  1. Change all global variables to properties in all classes, then test/commit/push/QA.
  2. Change all global properties to constructor parameters in all classes, and change instantiations of all classes, then test/commit/push/QA.

This may be a reasonable alternative for smaller codebases, but it comes with some problems, such as:

  1. The search for global calls becomes a little more difficult while converting globals to properties, because we will see the global keyword in both the converted and unconverted classes.
  2. The commits for each major step will be much larger and harder to read.

For these reasons and others, I think it's better to stay with the process as described. It works with large and small codebases, and keeps incremental changes in smaller easier-to-read portions.

Sometimes we will find that classes are instantiated based on variable values. For example, this creates an object based on the value of the $class variable:

page_script.php
1 <?php
2 // $type is defined earlier in the file, and then:
3 $class = $type . '_Record';
4 $record = new $class;
5 ?>

If $type is Blog, then the $record object will be of the class Blog_Record.

This kind of thing is very difficult to discover when searching for class instantiations to convert to using constructor parameters. I'm afraid I have no good advice for automatically finding these kinds of instantiations. The best we can do is to search for new\s+\$ without any class name, and modify the calls individually by hand.

Superglobals represent a challenging special case when removing global variables. They are automatically global within every scope, so they carry all the drawbacks of globals. We won't find them with a search for the global keyword (although we can search for them by name). Because they truly are global, we need to remove them from our classes just as much as we need to remove the global keyword.

We could pass a copy of each superglobal into the class when we need it. In cases where we need only one this might be fine, but frequently we need two or three or more superglobals. In addition, passing a copy of $_SESSION will not work as expected; PHP uses the actual superglobal of $_SESSION for writing session data, so changes to the copy will not be honored.

As a solution, we can use a Request data structure class. The Request encapsulates a copy of each of the non-$_SESSION superglobals. At the same time, the Request maintains a reference to $_SESSION so that changes to the object property are honored by the real $_SESSION superglobal.

Note

Note that the Request is not an HTTP request object per se. It is merely a representation of the request environment for PHP, including server, environment, and session values, many of which are not found in HTTP messages.

For example, say we have a class that uses $_POST, $_SERVER, and $_SESSION:

1 <?php
2 class PostTracker
3 {
4 public function incrementPostCount()
5 {
6 if ($_SERVER['REQUEST_METHOD'] != 'POST') {
7 return;
8 }
9
10 if (isset($_POST['increment_count'])) {
11 $_SESSION['post_count'] ++;
12 }
13 }
14 }
15 ?>

To replace these calls, we first create a shared Request object in our setup code.

includes/setup.php
1 <?php
2 // ...
3 $request = new \Mlaphp\Request($GLOBALS);
4 // ...
5 ?>

We can then decouple from the superglobals by injecting that shared Request object in to any class that needs it, and use the Request properties instead of the superglobals:

1 <?php
2 use Mlaphp\Request;
3
4 class PostTracker
5 {
6 public function __construct(Request $request)
7 {
8 $this->request = $request;
9 }
10
11 public function incrementPostCount()
12 {
13 if ($this->request->server['REQUEST_METHOD'] != 'POST') {
14 return;
15 }
16
17 if (isset($this->request->post['increment_count'])) {
18 $this->request->session['post_count'] ++;
19 }
20 }
21 }
22 ?>

Tip

If it is important to maintain changes to the superglobal values across scopes, be sure to use the same Request object throughout the application. Modifications to the values in one Request object will not be reflected in a different Request object, except for $session values (because they are all references to $_SESSION).

There is one more superglobal that PHP provides: $GLOBALS. Using this superglobal inside our classes and methods should be treated as a use of the global keyword. For example, $GLOBALS['foo'] is the equivalent of global $foo. We should remove it from our classes in just the same way as we do with uses of global.