LATEST BLOG ENTRY

Static methods are evil (full version)

May 13, 2010

Some months ago I tweeted that static methods are evil to which a colleague of mine who happens to be a flash developer responded “for silly PHP developers”. To be clear I’m not saying that static functions and static variables shouldn’t be used; quite frankly they’re in a lot of languages for a reason.

One reason why I call caution to it’s use can be found in nomenclature, it’s called “static” for a reason. If your code is littered with static function calls then you are missing the benefits of OOP and you’re really doing procedural programming (there is a time and place for procedural as well but I like calling a spade a spade).

A favorite use case of static variables for developers is to store data to be accessed globally. While seemingly convenient at implementation time it’s very annoying when it comes to debugging. Because a variable can be modified globally it becomes harder to reliably replicate bugs others might be experiencing or figure out where in the code the data is manipulated such that it causes an error. There are other ways to handle setting up objects with data e.g. inversion of control

Excess use of static functions also hinders unit testing for a couple reasons (in PHP at least). Successful unit testing depends on setting the application to a known state and comparing against an expected result. When data is stored statically test cases in a suite that leverage that data inadvertantly affect each other and making the outcome of those tests unreliable. Also it isn’t currently possible to stub static functions in PHPUnit which gets in the way of the setting application to a known state requirement. When you are developing a large application with regular releases TDD (test driven development) is your best friend.

My biggest gripe against static function and static variable use is that it gets in the way of polymorphism. I had the pleasure of leveraging a PHP library for a service and everything was done via static functions even setting the API keys. To make matters worse the service requires a couple steps to get going and all these steps were static function calls. Because the library was all static it wasn’t a simple class extention and overriding the functions; I ended up wrapping the class in an object to be able to do what I want and help out the next guy who has to leverage this code. In addition to making it difficult to customize, it was also difficult to use more than one account for the service. What makes OOP great is polymorphism; this concept is why code is reusable, and opensource thrives because while the original author envisioned certain uses, others have the oppurtunity to extend it without writing the whole thing over. It doesn’t hurt to think about the next guy touching this code, especially when that next guy is you.

So the next time you are about to use static functionality where an object would work just as well, in the words of Peter Griffin - c’moooon, c’mooon, c’mon

PREVIOUS ENTRIES

Service Layer in MVC

December 28, 2009

Zend Con 2009

October 26, 2009

Openhacknyc

October 12, 2009