public class Singleton{
private Singleton() {}
private static Singleton instance = null;
public static Singleton getInstance() {
if (instance == null){
instance = new Singleton();
}
return instance;
}
}
public Class CallSingleton {
public static void main(String[] args) {
Singleton single = Singleton.getInstance();
}
}
the variable instance is of type static. So once a static object is created it will be the same object that you will be accessing elsewhere from whatever the number of classes you have.
By Frank Carver
For me, a class is coupled very tightly to anywhere its name is mentioned in the code. I can't swap that class out for another implementation (one for testing, one for better performance, one for a different customer, whatever) without changing every occurrence of that name. Let's hope you have access to all the source code that uses your class!
That same class might be a lot less coupled if it implements an interface or extends a well-known base class, and the code always just refers to that interface or base class and doesn't care which class implements it. In that case, changing the implementation is very easy and localized, and needs no recompilation of code which uses it.
It's even possible to create a new implementation long after the code which uses it is compiled and deployed, and dynamically load it into a running program. Servers, in particular, use this approach a lot.
The Singleton pattern ties all the code which uses it very closely to a particular name and implementation. Whatever you call them, Singletons and statics are "global", and "globals" are well known for making understanding, maintenance and improvement of software harder and more expensive.
By Ilja Preuss
Besides the static reasons Frank mentioned, there is also a dynamic coupling. This coupling gets most obvious when you try to unit test classes using a Singleton (or even the Singleton itself). It's near to impossible to have the testcases being independent from one another without compromising the "only one instance" rule of the singleton.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
"If someone asks you to do something you don't know how to, don't tell I don't know, tell I can learn instead." - Myself
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
I'm also surprised that Dog (and indeed DogFactory) are abstract classes rather than interfaces. This approach makes it difficult to re-use existing test framework classes.
I also really don't like naming classes SomethingImpl - that's implied by the "extends" or "implements", so I always suggest using the name to say what's different about this one - but that's a different issue.
The difference is that the definition of the methods which must be provided by all Dog implementations is an interface in my version. By doing that I am free to create other completely different classes based on other, different base classes (perhaps a Servlet which is also a Dog, or a MockDog based on a test class as I describe above).
Originally posted by Frank Carver:
if you are creating it in main, you might as well just call "new", and then pass the created object in to classes which use it.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Mr. C Lamont Gilbert:
Yes but if you 'just create one' and pass it, then you will have LOTS of code involved in passing around a single object.
If this is your only purpose I would much rather use a singleton.
To be fair I have not experienced a situation where a singleton caused me an issue down the road that another implementation would not have caused.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Frank Carver:
I thought that was what you meant, really. I just relished the chance to appear more "extreme"![]()
Originally posted by Ga�tan Remy:
Hello all, first post for me, be gentle![]()
Don't you bring a dependency problem by using your 'Context'?
An object that used to only need knowledge of some kind of Logger, is now forced to depend on a full 'Context' interface.
I see that as a reusability problem, but maybe i'm wrong![]()
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Consider Paul's rocket mass heater. |