Tracking change and innovation in the enterprise software development community
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Free Book Offer
SOA Demystified
$40 Value
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
Posted by Geoffrey Wiseman on Aug 08, 2007
Google has released a tool that performs bytecode analysis in order to locate and report on Singletons within bytecode. Although Singletons are a common software pattern, many people consider them controversial, to be used carefully: arguments can be made both for and against. As stated in the project wiki:
The problem with singletons is that they introduce global state into a program, allowing anyone to access them at anytime (ignoring scope). Even worse, singletons are one of the most overused design patterns today, meaning that many people introduce this possibly detrimental global state in instances where it isn't even necessary.
[P]rograms using global state are very difficult to test ... When one class uses a singleton (and I'm talking about a classic singleton, one that enforces it own singularity thorough a static getInstance() method), the singleton user and the singleton become inextricably coupled together.
[R]elying on this static instance means that the signatures of methods no longer show their dependencies, because the method could pull a singleton “out of thin air.” This means that users need knowledge of the inner workings of code to properly use it, making it more difficult to use and test.
Because the dependencies of some given methods aren't clear when they rely on singletons, a tester may unknowing write two tests that actually depend on each other by modifying a shared resource.
The Google Singleton Detector can detect code that enforces its own singularity (singleton), helps enforce the singularity of another class (helper singleton, or 'hingleton'), returns state from a static methods without taking parameters (method singleton, or 'mingleton'), has a public static field (field singleton, or 'fingleton'), as well as code that directly relies on one of the above. You may hide some of these if you're not interested.
This is still a tool in a relatively early stage, and there are a few limitations:
Stay tuned to InfoQ for more information about code analysis, artifacts and tools and Google.
The 5 Mandates of Software Development Teams - Presto Manifesto
Regaining control of the data centre
Consolidation and Virtualization Are NOT Enough: The Case for Non-x86
This is actually a tool I have been wanting to write for years! Finally a way to fail the build when the crap accidentally enters the codebase ;-) Looking forward to trying it out.
One question you may think when reading this article is "Is there a better pattern/library to use in my Java applications instead of singletons?" I would recommend that you check out Guice, also from Google. It is a nifty tool that will replace singleton and factories in your code and in my experience, is really helpful when trying to insert mock instances during unit testing.
Alternatively, right click on source and search for 'static getInstance()' ??
...There being far more valid reasons to use singleton in a client side app than a server side app. It would be nice if the article distinguished the two. Still, like any pattern, it should be used judiciously, not capriciously. Poor use/Overuse of Singleton can cause problems for multi-threaded apps among other issues.
And...Believe it or not, people do occasionally write those thick client apps still.
That said, I'm interested in seeing how it handles the difference between a singleton and other "static" based construction techniques/patterns. Banning the appearance of static from your code seems a little too fanatical to me (which the guice page seems to imply would be a good thing).
The only valid Singleton (jvm or thread scoped) use case I see is when a context object can be needed by almost all methods of an application. Passing those objects as parameters everywhere just in case is just not pratical and very cumbersome so a singleton is a good solution in those cases in my opinion. A registry (Spring has a registry offers some singleton bootstrap classes) or the current user credentials are some good examples of this situation. Other than that I think that Singletons objects should be avoided and are an anti-pattern.
The only valid Singleton (jvm or thread scoped) use case I see is when a context object can be needed by almost all methods of an application. Passing those objects as parameters everywhere just in case is just not pratical and very cumbersome so a singleton is a good solution in those cases in my opinion. A registry (Spring has a registry offers some singleton bootstrap classes) or the current user credentials are some good examples of this situation. Other than that I think that Singletons objects should be avoided and are an anti-pattern.
Just wanted to add that with a good DI container able to inject dependances in any objects (including objects instancied directly throught the new keyword as Spring 2) there is almost no need anymore for Singletons except bootstrapping the container itself in some cases.
Hey, this is actually my project over at Google, and I just wanted to say a few things...
We actually can read bytecode form multiple jars now (it was a pain to extract some of the larger projects).
If you'd like to get an idea of the output GSD produces, check out my blog (davidrubel.blogspot.com/) for graphs of some common open source projects.
Also, we've been looking for a project in the open source community that used to be riddle with singletons and is now reliant on DI. Any suggestions?
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
7 comments
Watch Thread Reply