Different Perspective: Singleton as Dependency Management

I used to loath the singleton pattern, mostly because of the pain it has caused me whenever I take over some old code and try to write test on it. Interesting enough, Guidewire has used it in a way that is actually kind of cool.

If you have tried to manage component dependencies before the IoC container came out, you are probably fully aware of the pain you have to go through when a new dependency is introduced. Either you end up with a HUGE interface, or you have to change the signature of a handful classes and make some of them have longer parameter list in the process.

Here those dependencies are manager as "Dependencies" singleton interface. It is a set of static methods to be precise. So if a class decides it needs to use metadata layer to build the query and database layer to execute the query (like the archiving project that I am working on), it can just grab the instance by calling "PLDependencies.getExtractController()" and "DatabaseDependencies.getDatabase()". The dependencies are set up during the server initialization (through dependency registrations) and never changes.

There are some behavior changes associated with this design. Two on top of my head:

* No mocking/stubbing. Nothing is stubbed out within the application. We use H2 for testing and the database is reset using restore. So the tests run fairly fast. After seeing some horrible mocking code, I like this style more and more.
* Be aware of the dependencies. With dependency injection, you get used to understanding the dependency relationships by looking at the construction and method parameter list. With this design, surprises can really happen. You could very well call into something that does not take any parameter only to find out that it actually does a lot of things.

It is not the perfect design, but once you understand the pattern and learn not to abuse it, you can actually manage the dependencies quiet easily.

Test Coverage

http://www.artima.com/weblogs/viewpost.jsp?thread=204677

The above link got passed around at Guidewire the other day. It reminded me of the consulting days where we had to figure out the right answer for the right stage of the agile enablement.

This also reminded me about another interesting thing is this "90%, 50% rule" from Adam. He told me that he started paying more attention to the line coverage of the projects that he has been on. What he noticed is that the line coverages seem always end up at 90% or 50%. Normally 90% are the projects that developers are doing test-driven development, and 50% are the ones that people recognize that writing tests is an essential part of software development but not necessarily in the TDD fashion.

I do remember that all my projects in ThoughtWorks had the around 90% coverage. I wonder how much we have at Guidewire or my open source projects. The reason that I don't know is because at Guidewire the QA tests affects the coverage as well so it is not the same thing. My open source projects are all done in the TDD fashion so I never bothered to spend time create something that I don't really use.