Comments on: Beware of the Singleton

By: Ran Tavory

Ran Tavory — Thu, 01 Jul 2010 09:04:16 +0000

if in your code they are not singletons then that’s fine

By: Glide

Glide — Thu, 01 Jul 2010 08:40:42 +0000

If I’m using a framework like Spring and have all of the beans that Spring controls as singletons (by default I think)… but I’m using all of those beans as instance variables with setters and getters, is that still considered bad for unit testing?

For example:
class A {
SingletonBeanObject B;
public B getSingletonBeanObject(){//impl}
public void setB(SingleBeanObject){//impl}
}

By: Eran

Eran — Sat, 24 Oct 2009 14:30:51 +0000

2 other fun aspects of the Singleton pattern you forgot to mention, are the dependency cycles that usually get created by the ease of access, and the architectural violations (lower layers calling higher layers).

Although it is possible to create dependency cycles when using DI, it is impossible to do so when you use constructor injection only. Using constructor injection only, also allows you to write immutable classes which are thread safe, and less bug prone.

By: rantav

rantav — Thu, 25 Jun 2009 11:55:43 +0000

Hi Hagai, I agree that when used properly singletons don’t conflict with unit-tests.
Problem is that more often than not, what you’d see is that there’s an empty constructor (and only an empty one) and the singleton is hardcoded into the implementation which makes testing impossible.

I agree that when used correctly, a singleton is a powerful machanism,

By: Hagai Cibulski

Hagai Cibulski — Thu, 25 Jun 2009 10:55:55 +0000

IMO using singletons doesn’t conflict with resource decoupling for unit tests. E.g You could add a default constructor to DataBean that instantiates it with the real DB:

public DataBean() {
this(Database.INSTANCE);
}

and then producrtion code uses new DataBean() and test code uses new DataBean(new new ockDatabaseImplementation());