I need to create a singleton class without keeping a static method.
How can i do that?
Create an enum with one instance
enum Singleton {
INSTANCE;
private Field field = VALUE;
public Value method(Arg arg) { /* some code */ }
}
// You can use
Value v = Singleton.INSTANCE.method(arg);
EDIT: The Java Enum Tutorial shows you how to add fields and methods to an enum.
BTW: Often when you can use a Singleton, you don't really need one as utility class will do the same thing. The even shorter version is just
enum Utility {;
private static Field field = VALUE;
public static Value method(Arg arg) { /* some code */ }
}
// You can use
Value v = Utility.method(arg);
Where Singletons are useful is when they implement an interface. This is especially useful for testing when you using Dependency injection. (One of the weakness of using a Singleton or utility class substitution in unit tests)
e.g.
interface TimeService {
public long currentTimeMS();
}
// used when running the program in production.
enum VanillaTimeService implements TimeService {
INSTANCE;
public long currentTimeMS() { return System.currentTimeMS(); }
}
// used in testing.
class FixedTimeService implements TimeService {
private long currentTimeMS = 0;
public void currentTimeMS(long currentTimeMS) { this.currentTimeMS = currentTimeMS; }
public long currentTimeMS() { return currentTimeMS; }
}
As you can see, if your code uses TimeService everywhere, you can inject either the VanillaTimeService.INSTANCE or a new FixedTimeService() where you can control the time externally i.e. your time stamps will be the same every time you run the test.
In short, if you don't need your singleton to implement an interface, all you might need is a utility class.
public class Singleton {
public static final Singleton instance = new Singleton();
private Singleton() {}
public void foo() {}
}
then use
Singleton.instance.foo();
Another approach is the singleton holder idiom which offers initialization on demand:
public class Something {
private Something() {
}
private static class LazyHolder {
public static final Something INSTANCE = new Something();
}
public static Something getInstance() {
return LazyHolder.INSTANCE;
}
}
Note that standalone singletons like this should be avoided where possible because it promotes global state, leads to hard-to-unittest code and depends on a single classloader context to name a few possible drawbacks.
Follow the Joshua Bloch enum recipe in "Effective Java" 2nd edition. That's the best way to create a singleton.
I don't understand why this comes up so much. Isn't singleton a discredited design pattern? The GoF would vote it off the island today.
You can use one of IoC containers (e.g. Google Guice) and use your class as singleton(eager or lazy - it depends on your needs). It's easy and flexible as instantiating is controlled by IoC framework - you don't need any code changes if, for example, you will decide to make your class not singleton later.
Use an object factory, fetch your singleton object from this factory.
ObjectFactory factory;
....
MySingletonObject obj = factory.getInstance(MySingletonObject.class);
of course, there are many frameworks to help you to achieve this.
the spring framework is a popular choice.
From within constructor you need to chceck if there is already instance of the class somewhere. So you need to store reference to your singleton instance in static variable or class. Then in contructor of singleton I would always check if there is existing instance of singleton class. If yes I wouldnt do anything if not I would create it and set reference.
Related
I created a class with a public nested enum class and some setters. The nested enum class uses variables with values from a properties file set through dependency injection to the outer class. I want the component that uses the outer class to be agnostic of the values of the enum and loop through each one individually. The enum will always be instantiated after the outer class so there's no worry about null values in the variables. I was told this isn't how enums are supposed to be used. The suggestion is to write a class that mimics the enum class instead of just using the enum. That seemed very dogmatic and I'm curious what people's thoughts are and possible alternatives. I had written something like:
public class myOuterClass {
private static string1;
private static string2;
private static string3;
public enum NestedEnum {
MY_ENUM1("enum1: "+string1),
MY_ENUM2("enum2: "+string2),
MY_ENUM3("enum3: "+string3);
private String enumValue = "";
NestedEnum(String enumValue) {
this.enumValue = enumValue;
}
public String getEnumValue() { return enumValue; }
}
public String printEnum(NestedEnum enum) {
System.out.println(enum.getEnumValue());
return enum.getEnumValue();
}
public void setString1(String string1) {
this.string1 = string1;
}
public void setString2(String string2) {
this.string2 = string2;
}
public void setString3(String string3) {
this.string3 = string3;
}
}
The problem with your approach is that your enums are not actually dependency-injected; rather, they own their own instantiation logic (as enums always do), and they simply rely, in a fragile and unenforceable way, on dependency-injection having completed before the enum class is loaded by the class-loader. (Note that, since the enum is public, you aren't really controlling when this will happen; and neither is your DI framework.)
One way to fix this is to have your enum's constructor call into your DI framework. (For example, if you're using Guice and have a singleton instance of your Injector, your enum's constructor can ask it for the appropriate instances, thereby guaranteeing the ordering.) This is not ideal -- it pollutes your class code with references to your DI setup -- but it's better than what you have.
Another approach, of course, is not to use enum to begin with: let your DI framework do its job and manage your instances for you. But it sounds like you've already rejected that approach; and who am I to argue?
Edited to add: another potential issue with your approach is that the only way to "reset" your enums is by stopping and restarting the JVM. If you have multiple versions of your properties-file (e.g., different language versions), then your test-framework probably will not be able to test that they all work properly. (My first suggestion above does not address this issue.)
Below is my Interface -
public interface IDBClient {
public String read(String input);
public String write(String input);
}
This is my Implementation of the Interface -
public class DatabaseClient implements IDBClient {
#Override
public String read(String input) {
}
#Override
public String write(String input) {
}
}
Now I am thinking to write Thread Safe Singleton Factory to get the instance of DatabaseClient so that I can call read and write method accordingly.. So I wrote like this by following the Initialization On Demand Holder idiom, it is still incomplete -
public class DatabaseClientFactory {
public static DatabaseClientFactory getInstance() {
return ClientHolder.s_instance;
}
private static class ClientHolder {
}
}
And I am not sure how to get the instance of DatabaseClient correctly in my above Factory? Do I need to add another method getClient() to get the instance of DatabaseClient and then call like this -
IDBClient client = DatabaseClientFactory.getInstance().getClient();
client.read(input); // or client.write(input)
You shold use Initialization-on-demand holder idiom, implementing your factory:
public class DatabaseClientFactory {
private DatabaseClientFactory() {}
private static class LazyHolder {
private static final DatabaseClient INSTANCE = new DatabaseClient();
}
public static DatabaseClient getInstance() {
return LazyHolder.INSTANCE;
}
}
This code doesn't need synchronization because of the contract of the class loader:
the class loader loads classes when they are first accessed
all static initialization is executed before anyone can use class
class loader has its own synchronization that make previous two points guaranteed to be thread safe
Here is very a nice description of correct implementation of singleton from Joshua Bloch's (one of the Java's creators) "Effective Java" book. I would strictly recommend to read at least this chapter.
A few comments:
If you want your DatabaseClient to be singleton, you have to move your factory method to this class and make it's constructor private. Otherwise there is no guarantee, that everyone will use your factory and someone won't create the second instance of this class;
Even with such approach there is no guarantee, that someone won't use reflection to create new instance of your "singleton";
If you decide for some reason to make your DatabaseClient serializable - you'll expose another ability of getting the second instance of "singleton" and will have to apply some additional techniques to avoid this (which are also not always effective).
If you still decide to go this way - you can use one of the approaches suggested by "AgilePro" or "user987339" (with moving that logic to the DatabaseClient). I believe method, described by "user987339" is preferable as it will help to make this initialization really lazy. It's not really the case with approach described by "AgilePro" cause each call to some of the static methods of that class will initialize all static fields.
If you want to get really robust singleton - I suggest you to use enums. So your DatabaseClient will look like:
public enum DatabaseClient {
INSTANCE;
DatabaseClient() {
}
public String read(String input) {
}
public String write(String input) {
}
}
And its usage:
final DatabaseClient databaseClient = DatabaseClient.INSTANCE;
P.S. One more note related to all approaches: if you get some exception during initialization of DatabaseClient - you'll get "java.lang.ExceptionInInitializerError" which won't let you to initialize this class any longer (for all further calls to this class you'll get "java.lang.NoClassDefFoundError").
This is all you need:
public class DatabaseClientFactory {
private static final DatabaseClient mySingleton = new DatabaseClient();
public static IDBClient getInstance() {
return mySingleton;
}
}
Note the private static final member that holds the singleton instance. Declaring it final prevents you fromwriting code that might create another instance. In this case we construct as static initialization time which happens before any thread can possibly access it, but you could construct with lazy initialization at run time if you desired. In this latter case you would need to make the method synchronized, which is a bit more overhead.
I made the factory method return the interface, but it could if you wish be declared to return the concrete class instead. If your concrete class has some additional methods beyond the interface you may want to do the latter.
Access it like this
IDBClient client = DatabaseClientFactory.getInstance();
It is thread safe because the variable that holds the singleton object is initialized at static initialization time, before any thread can access it. Since it is never changed after that, there is no possibility of a race condition.
This approach is simpler than that other answer because this involves only two classes, which is all you need: the factory class and the client class. One of the other answers requires three classes. This is a very small difference, since an extra class is a very small overhead, but if you believe that code should remain as simple as possible for maintenance reasons, then using three classes when two would do is a waste.
Is this singleton design pattern correct ? I mean what's the need of checking the object is null or not when it's static and the method is synchronized .
public class MySingleton {
int val = 10;
private static final MySingleton singleton = new MySingleton();
private MySingleton() { }
public static synchronized MySingleton getSingleton() {
return singleton;
}
}
You don't need to make your method synchronized. The fact that the variable is initialized in a static initializer is enough. Also, your val variable should almost certainly be private...
The double-checked locking pattern (with the nullity checking) is usually used when you don't want a synchronized method and you don't want a static initializer. (To my mind it's unnecessarily complex and brittle in almost all cases.)
Another option would be to use an enum:
public enum MySingleton {
INSTANCE;
private int val = 10;
// Presumably something to use val
}
Using an enum enforces the singleton-ness and even gets it right in the face of serialization. It's also a pretty simple way of doing it with no actual code :) On the other hand, it's never felt entirely right to me...
You can do it like that, but in many cases you can use "lazy evaluation" - you create the instance the first time it is requested:
public class MySingleton {
private static MySingleton singleton = null
private MySingleton() { }
public static synchronized MySingleton getSingleton() {
if (singleton == null) {
singleton = new MySingleton();
}
return singleton;
}
}
The best pattern is the one given by Joshua Bloch in his book Effective Java, using an Enum :
public enum MySingleton {
INSTANCE;
public void doSomething() {
}
}
Quoting the book :
"This approach is functionally equivalent to the public field approach, except that it is more concise, provides the serialization machinery for free, and provides an ironclad guarantee against multiple instantiation, even in the face of sophisticated serialization or reflection attacks. While this approach has yet to be widely adopted, a single-element enum type is the best way to implement a singleton."
I have the following class :
public class EnteredValues {
private HashMap<String, String> mEnteredValues;
public boolean change = false;
public boolean submit = false;
private static final EnteredValues instance = new EnteredValues();
// Singleton
private EnteredValues() {
mEnteredValues = new HashMap<String, String>();
}
public static EnteredValues getInstance() {
return instance;
}
public void addValue(String id, String value) {
if (mEnteredValues.put(id, value) != null) {
// A change has happened
change = true;
}
}
public String getValueForIdentifier(String identifier) {
return mEnteredValues.get(identifier);
}
public HashMap<String, String> getEnteredValues() {
return mEnteredValues;
}
public void clean() {
mEnteredValues.clear();
change = false;
submit = false;
}
}
This class is used to manage the values that a user has already entered, and the class should be accessible to all classes across the application.
When the activity changes I 'reset' the singleton by calling the clear method.
I chose the singleton pattern without really considering the option of a static class.
But now I was wondering if I shouldn't just use a static class..
What is the common way to handle a class that just manages values?
Is a static class faster as a singleton?
thx
The very fact that you are providing a clear method to reset the state of your Singleton dictates that you should not use Singleton. This is risky behavior as the state is global. This also means that unit testing is going to be a big pain.
One more thing. Never ever declare instance variables as public. Declare them as private or protected and provide getters and setters. Also, there is no need to initialize instance variables with a value that is their default value.
The main difference between a static class and the singleton pattern is that singleton may be used if you need to implement an interface or such. For this particular case I think you might be better off with a static class since you are not implementing any interface. Relating your question if its one faster to the other, I'd say is negligible the difference but using a static class will remove a small overhead of dynamic instantiation of the class.
What is bad in using singleton if you need such a design? If you need exactly one instance of some object designed to do specified things singleton is not a bad choice for sure.
#see Are Java static calls more or less expensive than non-static calls?
Read
http://docs.oracle.com/javase/tutorial/java/javaOO/nested.html
From there:
Note: A static nested class interacts with the instance members of its outer class (and other classes) just like any other top-level class. In effect, a static nested class is behaviorally a top-level class that has been nested in another top-level class for packaging convenience.
Just for style
I prefer not to rely on Singleton if I don't need to. Why? Less cohesion. If it's a property you can set from outside, then you can test your Activity (or whatever) with unit testing. You can change your mind to use diferent instances if you like, and so on.
My humble advise is to have a property in each of your Activities (maybe you can define a common base class?), and set it at activity initialization with a new fresh instance.
Your code will not know nothing about how to get it (except the init code and maybe you can change it in the future).
But as I've said... just a matter of taste! :)
I have written the code shown below:
public class SiteMapFactory {
public static ISiteMap getSiteMap(Locale loc) {
ISiteMap returnMap = null;
if (loc.equals(Locale.US)) {
returnMap = SiteMap_en_US.getInstance();
}
if(loc.equals(new Locale("es","US"))){
returnMap = SiteMap_en_US.getInstance();
}
if(loc.equals(Locale.CANADA)){
returnMap = SiteMap_fr_CA.getInstance();
}
return returnMap;
}
}
I want to return the same site map for both en_US (English) and es_US (Spanish) of our website. So I am instantiating the US sitemap for both Spanish and English version (a third party vendor is converting our English pages to Spanish). The way the site map is instantiated is using singleton. Singleton object is created as follows:
public class SiteMap_en_US extends SiteMapTree {
private static SiteMap_en_US m_instance;
private SiteMap_en_US() {}
static {
m_instance = new SiteMap_en_US();
m_instance.init();
}
public static SiteMap_en_US getInstance(){
return m_instance;
}
#Override
protected void init() {
//some code
}
}
My question is: can I reuse the same singleton object twice? Is it a valid way of instantiating the singleton object?
Yes, you can reuse the same singleton object.
However: If you do this, you should not have to include any special handling within the object to determine which language it is being used for, it should simply behave the same way all the time.
If you have to make it behave differently, consider creating a subclass of SiteMap_en_US (SiteMap_es_US perhaps) that is derived from SiteMap_en_US and has a small number of behaviors overridden.
It's possible to do all sorts of locale checks within the object to determine its behavior, but I highly recommend considering a different approach that's easier to maintain.
You can create base class SiteMapUS and extend it to create two subclasses SiteMapUSEnglish and SiteMapUSSpanish.
public class SiteMapUS{
protected SiteMapUS(){
}
}
public class SiteMapUSEnglish{
protected SiteMapUSEnglish(){
}
public SiteMapUSEnglish getInstance(){
//return instance
}
}
public class SiteMapUSSpanish{
protected SiteMapUSSpanish(){
}
public SiteMapUSSpanish getInstance(){
//return instance
}
}
place all classes in separate package.
This is the simplest way to achieve your goal. Benefit of using this approach is that you can easily modify/add locale related changes without modifying other code.
This is why many agree that Singleton is an anti-pattern. You need multiple instances of the object, one for each locale. It's not a singleton. I like to say that Singleton is just a euphemism for global variables. You're basically allowing a global way to access the Locales.
Singleton - The anti pattern