Mark Baker continues his series looking at the use of static properties and methods in applications and how to test them. In this second part of the series he focuses more on some of the unintentional side-effects that could happen when you're trying to refactor them out.

In the first article in this series, I wrote about the problems with testing static methods in classes, and showed a few approaches that allow us to write mocks for statics. Testing classes where we have static properties is a lot harder to manage, because any changes made in any test to those properties are global, across the entire test suite, not simply the test that we are running. Static properties are part of the global state, and we can’t simply tearDown() those changes in the way that we do with instances — at least we cannot easily do so if the property has a visibility of private or protected.

He goes through an example of a refactor from a static property (essentially in the global scope) to a private property. He points out the issue of setting a static value in what seem to be separate child classes, the fact that it actually changes the base value, not the individual ones, leading to potentially unintended consequences.

His main recommendation is to avoid the use of static properties all together. Where that's no possible (like in a legacy project) he offers two potential solutions: either replace them with constants if they're never changed or changing them to instance properties.

Yannick Mahe has posted some thoughts (from personal experience) about living with a legacy framework and some of the consequences that come with it. In his case, it's a Symfony 1.0-based application that would require a complete rewrite to migrate even up to the Symfony 2.x range.

At our company, our main web app is based on Symfony 1.0, a PHP framework released in 2008. It was developed by a company called Sensio and open-sourced shortly after. It was a great framework when it came out, with all the good ideas from Ruby On Rails, CakePHP, etc. as well as great documentation, tutorials and a growing community.

[...] Since that framework came out, its subsequent versions, Symfony 1.1, 1.2, 1.3, 1.4 came out and died out. The 1.4 version came with a 3 year long term support promise from Sensio which ended in 2012. All the 1.X versions are based on the same overall architecture, and same principles. Sensio also released Symfony 2.0, 2.1, 2.2 and very recently, 2.3. which have a whole new architecture.

He talks about some reasons why they're not migrating (the risk involved, the product focus, etc) and some of the trials they did to see what kind of effort would be involved. He then puts some context around working with a legacy framework, pointing out that:

• You can no longer rely on the community and time is lost figuring things out yourself
• Documentation is harder to find
• The ecosystem (ex. plugins) is no longer seeing new features or updates
• The compatibility issues with newer versions of PHP