Introducing static

The keyword static now enables us to use methods and properties (state) per-class and not on a per-object basis. This basically leaves us with class oriented programming. This seems to make a lot of things simpler, at a first glance, but will almost certainly hurt you in the long term.

Why? Let's start with some examples. And yes, I have done all this myself during the past years and you will find examples of static misuse in almost every library out there.

Testing

If you start unit-testing your code you will quickly notice why static dependencies are so bad - because it becomes almost impossible to replace implementations during testing, so that you often end up testing your full framework stack or need to write dozens of helper classes just for the sake of testability. And you would not need that without static dependencies.

Let's consider the trivial example above again - when testing the doSomething() method in a unit test we would not want it to operate on the file system directly - because it is slow and most probably not relevant to the test case. For testing you would want to replace FileTool by a mock just returning canned data or an alternative implementation using something like vfsStream - a PHP stream wrapper which operates in memory.

If the object on which you call the doSomething() method now aggregates a FileTool object instead of the static call you could just pass another object implementing the same interface to the tested object and an alternative implementation would be used. In case of unit tests you could use PHPUnit's mocking features to automatically generate a mock object for you, which then is passed to the object. (There are also various other mock object libraries out there.)

In non-trivial applications this might result in complex object graphs, since the FileTool might not only be used by one type of objects, but in multiple places all over the application. This is especially true for Loggers or similar ubiquitous types. Passing (all) dependencies of a type to the object of the type is called dependency injection - and to build object graphs in complex applications, re-using the same objects for one type, can be done easily using dependency injection containers (DIC). But this is a topic for another blog post.

PHPillow

PHPillow is just a simple wrapper to access CouchDB, which synchronizes views and offers simple features for document validation. While you can just perform arbitrary requests against CouchDB using PHPillow it also allows you to define a document, including simple validation constraints for its properties, and store / retrieve them from the database.

I started developing PHPillow when Late Static Binding (LSB) had been introduced in PHPs trunk. Wanting to play with a new language feature and developing a library seldom ends up well, and thus PHPillow used static and LSB all over the place. By now we replaced some of those parts and you can use most of PHPillow also non-statically - bot not everything.

One thing, which is still left in the code, is the creation of response objects from CouchDBs HTTP responses. CouchDB itself returns JSON structures, which, together with HTTP status code of the response, tell you what happened and provide you the requested data. The data looks different in case of errors, view requests, document listings or when requesting a single document.

In PHPillow there is a phpillowResponseFactory with a static method parse(), which creates the proper response object from the JSON and HTTP response data. The parse() method is then called in the different connection handlers to create the response objects.

If CouchDB now implements a new feature, which emits an entirely different response type, you could request this using PHPillow, since you can basically perform any HTTP request, but the response factory would most probably need some adaption. But because of the static reference in the connection handlers, a user of the library could only do that by patching the response factories source code. If the connection handlers now would aggregate the response factory (and maybe use some default implementation) the user of the library could just inject his own response factory and be fine.

This is the classic example of a static dependency which makes it virtually impossible to adapt or enhance functionality in an existing library. PHPillow has a quite high test coverage, but the connection handler tests can obviously not be real unit tests, since they always also cover the response factory. There is also no sane way to replace it during the tests by a mock.

Zend Framework

There is a particularly bad example for static dependencies in the Zend Framework, which actually makes their OpenID component unusable for any project which is not based on the Zend Framework MVC stack. The idea of a loosely coupled, reusable component framework is destroyed by a single static method.

I was evaluating Zend_OpenId as an alternative for an OpenID implementation for Arbit. An OpenID consumer, which I was looking for, is required to perform HTTP redirects - this is not easy to integrate in a library since this most likely involves the whole MVC stack. You might just want to return the HTTP header and shut down or clean up your application framework or you might also echo some HTML / JavaScript also performing the redirect. An OpenID library thus requires some kind of callback for the application to hook into.

In Zend_OpenId the static method Zend_OpenId::redirect() is used to execute the HTTP redirect. This method depends on Zend_Controller_Response_Abstract, thus the Controller component from the Zend Framework - which you do not want to use if you are already using a different MVC implementation. Since the method is called statically in the consumer and the provider implementation there is no easy way to replace the implementation with something working for you.

Additionally, in the consumer, the call to the static method redirect() is executed in a method with > 80 lines of code - so replacing the implementation of the calling method isn't really an option, either. Replacing such a long method would require massive copy & paste - and you would, for example, never again benefit of bug fixes in that method.

This example shows how a single static method call can make a whole component unusable for many potential users by adding static dependencies. Those static dependencies are often not easy to refactor out of the code. In this case a redirector interface with a default implementation working on the Zend Framework MVC stack would probably work, though.

Symfony

Symfony 1 uses static quite extensively - looking at the symfony 2 source code it got better. But there are still some occurences, which, most probably, will hurt in the long run. On the other hand, as of today, symfony 2 is still under development and this might change until its final release.

Even this is not the only usage of static I want to point to a very simple example: A utility class. Utility classes, performing small re-occuring jobs, are a very common use case for static methods, since they provide very simple functions and it is so much easier to just call them statically and not require a object to be passed as a dependency to the calling object.

There are a lot common utility classes, like for file handling, escaping, or in this case, for checking if a number is in a given interval. The class Symfony\Component\Translation\\Interval basically exposes one important public static method test($number, $interval), which tests if a number is contained in a defined interval. As you can see in the source of that class, the method is not entirely trivial. The method is used statically in the MessageSelector - which means that there is no way to replace the call to the interval checking other the re-implementing the MessageSelector itself.

So, if the interval checking, or the used regular expression, now contains a bug there is no way for you to fix the bug, other then patching foreign code. This violates the Open-Closed-Principle, which basically boils down to:

You should be able to change behaviour without touching a components code. (See S.O.L.I.D.)

It seems wrong on the first hand sight to use dependency injection for small stupid things like usually implemented by utility classes, at first. Why should I inject objects for recursive file deletion, escaping or simply test if a numer is contained in a given interval? But once you hit a bug in that code, or need to change the behaiviour of the utility class you'll wish you had done this from the very beginning.

This gets worse if the utility class depends on static properties, a global state, for doing its job. An utility class for escaping could, for example, contain a static property specifying the encoding of the strings it is used with. Now two different code paths in your application, both using the escaping utility, can influence themselves by changing the (default) encoding used by the utility class.

Apache Zeta Components

Checking the Apache Zeta Components, there is not much usage of static. There is one class implementing a singleton, the WebDAV server and some classes providing registries, like in the database component.

We all, by now, know that Singletons are bad, since they are just sophisticated global variables. Luckily it is easy and backwards compatible to just make it possible to instantiate the WebDAV server multiple times by making the __construct() method public again.

But why are registries also a bad thing? They offer a dedicated extension point after all.

The database component, for example, allows you to manage multiple connections using the ezcDatabase::setInstance( 'name', $connection );. This makes it possible to create and use any number of database connections and there are no limits on what kind of connection you inject and will use in your application.

The problem lies with the registry itself. If your application now uses the ezcDatabase registry there is a hard dependency on that particular registry. If the registry now contains a bug you might not have commit access to the Apache Zeta Components source code to fix it right away. On the other hand it would probably be very tedious to adapt all calls to the registry (imagine people are writing modules following your coding standards and you do not have access to all those modules source code using the registry).

And besides potential bugs in the registry you also might want to extend the registry at some point. For example it could be sensible to return different different connection for read and write access to the database, or something alike. In any case the static dependency on the registry might limit your abilities to extend your application.

Additionally registries add dependencies to your class which cannot easily be detected by the reader of your source code. All object your object depends on which are explicitly passed to the constructor are quite obvious. Everything else, constructed in the class, or fetched from global singletons or registries can be really hard to detect. This again makes your code harder to maintain.

Luckily, in the database component, using the registry is optional and you can just use the plain connection handlers and inject those objects like you should do.

test at Wednesday, 2.3. 2011

Hello world

This is, interestingly, often the first point you here when arguing about static. Until now I didn't see any application where the difference is relevant in any way. For the case the microsecronds are really relevant to you you should probably think about using plain functions or switch to another language (maybe Assembler?).

For me maintainability and the absence of a global state is far more important because it makes your code easier to extend, easier to read and thus easier to maintain.