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

The biggest revelation was that my application of MVC was “wrong”. I put wrong in quotes because application architecture (similar to beauty) is in the eye of beholder. There are many schools of thought on how you should go about architecting but choosing a path is difficult.  Often these techniques are phrased as making code more scalable and maintainable but without clear examples of why certain things are wrong and why others are right. Patterns of Enterprise Architecture by Martin Fowler does a good job of introducing commonly used patterns but even Martin concedes in the book that he has no idea what you are building; he can only point you in the somewhat correct direction

I’ve had the opportunity to work on and architect some great application (websites) early in my career and I’m currently working on one of my own that I hope will stand the test of time. In a series of posts I hope to identify what I did wrong what I think is right by using UML, diagrams, and some code to model a common application – a blog. We’ll start with my mangled MVC thoughts, move to a more acceptable MVC technique and then end at what I understand to be domain driven development.

1. Swapping  out data sources is easier. The controllers no longer need to know any thing about the models just the api needed to access data from the service. That service could go from leveraging models that access a local database or an api used to interact with external data.
2. Because the models are out of site from the controllers it becomes easier to upgrade or change the model layer with out too much adverse effect on the business logic (e.g. I’d like to upgrade a bunch of projects to doctrine)
3. Services are more portable. Currently I leverage a restrictive MVC pattern where “user” functionality goes through a UserController which in turn leverages a table gateway patter that is made up of a Users class (the gateway) and User (row class). This works out great for code generation but inconvenient to work with in a large application because the functionality is so siloed.
4. Exposing an api for 3rd parties to leverage is a bit more straightforward.

So I’m sold on the Service Layer concept now to get it hooked into my Zend Framework setup. We’ll check that out in the next post

Press: Commart Pick Of The Week, Press Release