Why Singleton completely removes the possibility of using interfaces?

[bqiao]

I know what a singleton is and how wonderful programming to interface is. Well, at least I think I do.

But I can't figure out why singleton completely removes the possibility of using interfaces as said in "Pro Spring"? With limited experiences in Java, I can't imagine a scenario where a singleton implementing an interface can not be used by an object requiring that interface.

Can someboy enlighten me with an example please?

Thanks for your help!

[jbetancourt]

Does it really say that? I have the book but don't remember that.

Note that when you create beans using Spring the default instantiation mode is 'singleton'. So by default one naturally programs to interfaces but uses singletons. What I think is different is the use of the Singleton Pattern. In Spring, the SP's main drawback, the lookup of the Singleton, is mitigated.

[bqiao]

Thanks for your reply.

Yes, it was about Singleton pattern.

My last post was a bit out of context.

This is mentioned in Configuring the BeanFactory of Chapter 4 as follows:

"In reality, the Singleton pattern is actually two patterns in one. The first, and desired, pattern involves maintenance of a single instance of an object. The second, and less desirable, is a pattern for object lookup that completely removes the possibility of using interfaces"

I don't understand in what circumstances Singleton can hamper the use of interface, compared to ordinary classes.

Many thanks

[cepage]

"In reality, the Singleton pattern is actually two patterns in one. The first, and desired, pattern involves maintenance of a single instance of an object. The second, and less desirable, is a pattern for object lookup that completely removes the possibility of using interfaces"

Perhaps it would be clearer to say that the Singleton Pattern removes the possibility of using only interfaces in your client code.

With the pattern, I must use:

MyImplementation.getInstance()

I can't use:

MyInterface.getInstance()

With the Spring alternative I can simply use:

public void setMyInterface( MyInterface myInterface )
{
_myInterface = myInterface;
}

Clearly, the Spring approach is much better for programming to interfaces without a dependency on the implementation class.