I have common code (multiple class that I call controllers) that needs to be shared by multiple packages in the project.
I was thinking of creating a factory, that returns these controllers.
So, the factory would have a hashmap, that can return the controller asked for or create a new one if not created.
The controllers have common code and since I don't need to create multiple instances of these controller, I think they should be singletons.
Does this seem like a good approach?
I think what you need is a Multiton pattern.
The multiton pattern is a design pattern similar to the singleton,
which allows only one
instance of a class to be created. The multiton pattern expands on the
singleton concept to manage a map of named instances as key-value
pairs. Rather than have a single instance per application (e.g. the
java.lang.Runtime object in the Java programming language) the
multiton pattern instead ensures a single instance per key.
public class FooMultiton {
private static final Map<Object, FooMultiton> instances = new HashMap<Object, FooMultiton>();
private FooMultiton() {
// no explicit implementation
}
public static synchronized FooMultiton getInstance(Object key) {
// Our "per key" singleton
FooMultiton instance = instances.get(key);
if (instance == null) {
// Lazily create instance
instance = new FooMultiton();
// Add it to map
instances.put(key, instance);
}
return instance;
}
// other fields and methods ...
}
The controllers have common code and since I don't need to create
multiple instances of these controller, I think they should be
singletons.
You need single instance does not necessarily mean that you need a Singleton Pattern. You can have a single instance and pass that on subsequent calls to that. Don't necessarily enforce singletonness using private constructor.
Also read Evil Singletons for more on down points of Singletons. After reading that if you still feel you need Singleton then go with it.
Yes it does. The Singleton design pattern suffer for several problems, one of which is that Singletons cannot be extended.
However, if you retrieve these controllers via a ControllerFactory.createControllerX() instead of ControllerX.getInstace(), you will be able to extended ControllerX in future and all its client will not be aware of using an extended version. Which is a really good thing
Related
Recently, when I ask how to make methods thread-safe in singleton pattern, someone told me that using an enum version singleton pattern is a good option. and by multiple threads. If the method has side effects (changes the state of some variable) then you need to think about protecting it (make it synchronized) or parts thereof. So I write code like this:
public enum ReStation {
INSTANCE;
private List<Email> emailList;
private ReStation() {
emailList = new ArrayList<>();
}
public synchronized void recycleEmail(Email email) {
System.out.println("Recycle station recycleing the email: "
+ email.getContent());
emailList.add(email);
}
public synchronized void deleteEmail(Email email) {
emailList.remove(email);
}
public synchronized void clear() {
emailList.clear();
}
}
however, when I read the book named "Design Pattern-Elements of Reusable Object-Oriented Software", I come across such a paragraph as below :
Applicability
Use the Singleton pattern when
• there must be exactly one instance of a class, and it must be accessible to
clients from a well-known access point.
• when the sole instance should be extensible by subclassing, and clients
should be able to use an extended instance without modifying their code.
Given an enum can't be extended, I am really confused about How could I use an extended instance without modifying their code while using an enum version singleton pattern? is modifying singleton class codes the only way to extend the functionality of the singleton?
When the quote says the "sole instance should be extensible by subclassing", they are talking about situations where:
You need a single distinguished instance of a base class or interface, with a well-known access point, like the process Logger;
You need to choose the concrete implementation at runtime, for example based on configuration or other runtime information. Your process Logger, for example, could be implemented by FileLogger or ConsoleLogger. Usually, it should be possible to use any Logger subclass to implement the system logger.
You can't do this with the "enum version singleton pattern".
There is a standalone Java application. In it there is a factory method which is called once and creates only one object (if it is possible to create it). I have two questions - which pattern is better for this? And secondly- is it correct to store the object that creates the factory in the factory itself in this case?
The design pattern is Singleton. It's correct to store the object in the factory like the sample. When use singleton, it checks the attribute if it's null. It creates new object if the attribute is null.
The most common pattern for creating a single object in Java is the Singleton Pattern. According to Design Patterns: Elements of Reusable Object-Oriented Software that recorded the pattern, the purpose of the Singleton Pattern is as follows:
Ensure a class only has one instance, and provide a global point of
access to it
There are two ways to create a singleton object: Eagerly and lazily. Eager instantiation is simple because it amounts to the creation of an object and returning it through a getter:
public EagerSingleton {
private static final EagerSingleton INSTANCE = new EagerSingleton();
private EagerSingleton() {}
public static EagerSingleton getInstance() {
return INSTANCE;
}
}
If the creation of the object is expensive (and therefore should be delayed as long as possible) or if there is a reasonable chance that the object may never be needed, it may be a good idea to instantiate the singleton lazily. This is a deceptively difficult task because multiple threads may access the lazily instantiated object and the implementation must ensure that only one object is ever created, regardless of the number of concurrent accessed to the object (i.e. if two threads both see that the singleton has not been created, only one object should be created, not two, and used by both threads).
The safe way to implement a lazy singleton is as follows:
public class Singleton {
private static class SingletonHolder {
public static final Singleton instance = new Singleton();
}
public static Singleton getInstance() {
return SingletonHolder.instance;
}
}
This ensures that the nested static object is not created until getInstance is called. There are a number of optimizations of this scheme, but unless performance is severely needed, the above should be used. Custom implementations of this pattern are difficult to make safe.
Factory seems to be adapted to your requirement.
Note that if you want to master the number of instances of the objects created, a simple way would be to define the class of the instance to create as the factory class itself by defining a private constructor and a static method to create the object is a way.
Note that this way may create a strong coupling between the implementation and its clients. So you could use a less coupled solution such as dependency injection or implementations using an interface.
It's better to use Singleton design pattern when you want to create an object only once and which can be used throughout the application. If you are using factory design pattern for creating only one object and used throughout the application then you may use Singleton pattern for this.
In order to create factory of factory objects then use Abstract Factory design pattern.
I have written 60 Java/J2EE design patterns.
Please refer the link - https://ramesh-java-design-patterns.blogspot.in/
We keep reading about how to use 'readResolve()' to ensure singleness in case of serializing a Singleton. But what are practical use cases for wanting to serialize a Singleton in the first place?
EDIT: pl. note: the question is about why to serialize a Singleton, and not about what's a safe way to do so.
The most common case would be where you have an object representing a large data structure (e.g. a tree of nodes in a XML-style document).
This data structure could easily contain singleton values (e.g. singleton instances that represent the data type of a particular attribute attached to a node in the tree). Many different nodes in the tree could point to the same shared singleton value.
There are many circumstances where you might want to serialise such a data structure, e.g. sending a copy of the object over the network. In this case you would also need to serialise the singleton values.
But then when you read the data structure back in, you want to use the existing value of the singleton, not a newly created instance. This is why you need readResolve()
Joshua Bloch Effective Java (2nd Edition) suggest to use Enum as singleton. It is always created by VM and it is impossible (or hard) to create second instance of singleton.
For normal singleton you can always "hack" the system, see:
Singleton Pattern
Hot Spot:
Multithreading - A special care should be taken when singleton has to be used in a multithreading application.
Serialization - When Singletons are implementing Serializable interface they have to implement readResolve method in order to avoid having 2 different objects.
Classloaders - If the Singleton class is loaded by 2 different class loaders we'll have 2 different classes, one for each class loader.
Global Access Point represented by the class name - The singleton instance is obtained using the class name. At the first view this is an easy way to access it, but it is not very flexible. If we need to replace the Sigleton class, all the references in the code should be changed accordinglly.
The object may be a singleton, but it may be part of a larger structure which doesn't quite know it is. For example, it may implement an interface which can have several different implementations (and thus, instances):
interface StringSink extends Serializable { void dump(String s); }
class MultiDumper implements Serializable {
private final StringSink sink;
public MultiDumper(StringSink sink){ this.sink = sink; }
void doSomeStuff(Collection<String> strings){
for (String s : strings) sink.dump(s);
}
}
Now, let's say we want a StringSink which dumps strings to stdout. Since there's only one stdout, we might as well make it a singleton:
/** Beware: Not good for serializing! */
class StdoutStringSink {
public static final StdoutStringSink INSTANCE = new StdoutStringSink();
private StdoutStringSink(){}
#Override
public void dump(String s){ System.out.println(s); }
}
And we use it like this:
MultiDumper dumper = new MultiDumper(StdoutStringSink.INSTANCE);
If you were to serialize, and then deserialize this dumper, you'd have two StdoutStringSink instances floating around in your program.
I understand that a singleton class is one where there can be only one instantiation, but I don't understand why this would be useful. Why won't you just create a class with static variables and methods and use synchronize if needed to make sure that no two threads were executing a method in the class simultaneously. I just don't get why anyone would go through the trouble of creating this kind of class. I know I'm missing something here.
Thanks,
While I agree with the other answers, the OP was asking why not have a class with all static methods (possibly with static fields) instead of a singleton where you have one instance.
Why use Singletons?
You can Google "singleton" to find all sorts of reasons. From JavaWorld:
Sometimes it's appropriate to have
exactly one instance of a class:
window managers, print spoolers, and
filesystems are prototypical examples.
Typically, those types of
objects—known as singletons—are
accessed by disparate objects
throughout a software system, and
therefore require a global point of
access. Of course, just when you're
certain you will never need more than
one instance, it's a good bet you'll
change your mind.
Why use a Singleton instead of a class with all static methods?
A few reasons
You could use inheritance
You can use interfaces
It makes it easier to do unit testing of the singleton class itself
It makes it possible to do unit testing of code that depends on the singleton
For #3, if your Singleton was a database connection pool, you want to insure that your application has only one instance, but do unit testing of the database connection pool itself without hitting the database (possibly by using a package-scope constructor or static creational method):
public class DatabaseConnectionPool {
private static class SingletonHolder {
public static DatabaseConnectionPool instance = new DatabaseConnectionPool(
new MySqlStatementSupplier());
}
private final Supplier<Statement> statementSupplier;
private DatabaseConnectionPool(Supplier<Statement> statementSupplier) {
this.statementSupplier = statementSupplier;
}
/* Visibile for testing */
static DatabaseConnectionPool createInstanceForTest(Supplier<Statement> s) {
return new DatabaseConnectionPool(s);
}
public static DatabaseConnectionPool getInstance() {
return SingletonHolder.instance;
}
// more code here
}
(notice the use of the Initialization On Demand Holder pattern)
You can then do testing of the DatabaseConnectionPool by using the package-scope createInstanceForTest method.
Note, however, that having a static getInstance() method can cause "static cling", where code that depends on your singleton cannot be unit tested. Static singletons are often not considered a good practice because of this (see this blog post)
Instead, you could use a dependency injection framework like Spring or Guice to insure that your class has only one instance in production, while still allowing code that uses the class to be testable. Since the methods in the Singleton aren't static, you could use a mocking framework like JMock to mock your singleton in tests.
A class with only static methods (and a private contructor) is a variant where there is no instance at all (0 instances).
A singleton is a class for which there is exactly 1 instance.
Those are different things and have different use cases. The most important thing is state. A singleton typically guards access to something of which there is logically only ever one. For instance, -the- screen in an application might be represented by a singleton. When the singleton is created, resources and connections to this one thing are initialized.
This is a big difference with a utility class with static methods - there is no state involved there. If there was, you would have to check (in a synchronized block) if the state was already created and then initialize it on demand (lazily). For some problems this is indeed a solution, but you pay for it in terms of overhead for each method call.
Database instances is one place singletons are useful, since a thread only wants one DB connection. I bet there are a lot of other instances like database connections where you only want one instance of something and this is where you would use a singleton.
For me the reason to prefer singleton over a class with static methods is testability. Let's say that I actually need to ensure that there really is one and only one instance of a class. I could do that with either a singleton or a static class with only static methods. Let's also say that I'd like to use this class in another class, but for testing purposes I'd like to mock the first class out. The only way to do that is to inject an instance of the class into the second class and that requires that you have a non-static class. You still have some pain with respect to testing -- you might need to build in some code you can invoke with reflection to delete the singleton for test purposes. You can also use interfaces (though that would explicitly would allow the use of something other than the singleton by another developer) and simply provide the singleton as an instance of the interface to the class that uses it.
One consideration is that making a singleton an instance allows you to implement an interface. Just because you want to control instantiation to it, does not mean you want every piece of code to know that it's a singleton.
For example, imagine you had a connection provider singleton that creates DB connections.
public class DBConnectionProvider implements ConnectionProvider {}
If it were a class with static methods, you couldn't inject the dependency, like this:
public void doSomeDatabaseAction(ConnectionProvider cp) {
cp.createConnection().execute("DROP blah;");
}
It would have to be
public void doSomeDatabaseAction() {
DBConnectionProvider.createConnection().execute("DROP blah;");
}
Dependency injection is useful if you later want to unit test your method (you could pass in a mocked connection provider instead) among other things.
Use the singleton pattern to encapsulate a resource that should only ever be created (initialised) once per application. You usually do this for resources that manage access to a shared entity, such as a database. A singleton can control how many concurrent threads can access that shared resource. i.e. because there is a single database connection pool it can control how many database connections are handed out to those threads that want them. A Logger is another example, whereby the logger ensures that access to the shared resource (an external file) can be managed appropriately. Oftentimes singletons are also used to load resources that are expensive (slow) to create.
You typically create a singleton like so, synchronising on getInstance:
public class Singleton {
private static Singleton instance;
private Singleton(){
// create resource here
}
public static synchronized Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
}
But it is equally valid to create it like so,
public class Singleton {
private static Singleton instance = new Singleton();
private Singleton(){
// create resource here
}
public static Singleton getInstance() {
return instance;
}
}
Both methods will create a single instance PER classloader.
A singleton has the advantatage over a class with static variables and methods : it's an object instance, which can inherit from a class (example : an application that ahas a single principal JFrame), and extend one or more interfaces (and thus be treated as any other object implementing these interfaces).
Some people think that singletons are useless and dangerous. I don't completely agree, but some points about it are valid, and singletons should be used carefully.
Static classes used in place of singletons are even worse in my opinion. Static classes should be mainly used to group related functions which don't share a common resource. java.util.Collections is a good example. It's just a bunch of functions that aren't tied to any object.
Singletons, on the other hand, are true objects. Ideally, singleton should be implemented without singleton pattern in mind. This will allow you to easily switch to using multiple instances if you suddenly need it. For example, you may have only one database connection, but then you have to work with another, completely unrelated database at the same time. You just turn your singleton into a "doubleton" or "tripleton" or whatever. If you need, you can also make its constructor public which will allow creation of as many instances as you want. All this stuff isn't so easy to implement with static classes.
Simply put, a singleton is a regular class that has one instance globally available, to save you from all the trouble of passing it everywhere as a parameter.
And there is not much trouble in creating a singleton. You just create a regular class with a private constructor, then implement one factory method, and you're done.
When would you need to use one?
There are many objects we only need one of: thread pools, caches, dialog boxes, objects that handle preferences and registry settings, objects used for logging, and objects that act as device drivers to devices like printers and graphic cards. For many of these types of object if we were to intantiate more than one we would run intol all sorts of problems like incorrect program behavior or overuse of resources
Regarding the usage of synchronization it is definitly expensive and the only time syncrhonization is relevant is for the first time or the unique instatiation once instantiated we have no further need to synchronize again. After the first time through, syncrhonization is totally unneeded overhead :(
Others have provided better answers while I was replying, but I'll leave my answer for posterity. It would appear unit testing is the big motivator here.
For all intents and purposes, there is no reason to prefer a singleton to the approach you described. Someone decided that static variables are capital-b Bad (like other sometimes useful features like gotos) because they're not far off from global data and in response we have the workaround of singletons.
They are also used with other patterns. See Can an observable class be constructed as a singleton?
I've found three ways of instantiating a Singleton, but I have doubts as to whether any of them is the best there is. I'm using them in a multi-threaded environment and prefer lazy instantiation.
Sample 1:
private static final ClassName INSTANCE = new ClassName();
public static ClassName getInstance() {
return INSTANCE;
}
Sample 2:
private static class SingletonHolder {
public static final ClassName INSTANCE = new ClassName();
}
public static ClassName getInstance() {
return SingletonHolder.INSTANCE;
}
Sample 3:
private static ClassName INSTANCE;
public static synchronized ClassName getInstance()
{
if (INSTANCE == null)
INSTANCE = new ClassName();
return INSTANCE;
}
The project I'm using ATM uses Sample 2 everywhere, but I kind of like Sample 3 more. There is also the Enum version, but I just don't get it.
The question here is - in which cases I should/shouldn't use any of these variations? I'm not looking for lengthy explanations though (there's plenty of other topics about that, but they all eventually turn into arguing IMO), I'd like it to be understandable with few words.
The most secure and easy way to implement a singleton in java is by using enums (like you mentioned):
public enum ClassName {
INSTANCE;
// fields, setters and getters
}
The enum semantics guarantees that there will be only one INSTANCE
If not using the enum approach, you must take care of quite a lot aspects, like race conditions and reflection. I've been breaking singletons of some frameworks, and abusing them, because they weren't properly written. The enum guarantees no one will break it.
Sample 1 does not use lazy initialisation.
Sample 2 and 3 are both lazy. Sample 2 uses the Initialization on demand holder idiom (IODH) which has no synchronisation overhead. Therefore it is faster than Sample 3.
In Effective Java (Item 3), Joshua Bloch recommends that a single-element enum type is the best way to implement a singleton.
However, if you are unsure about the enum type, stick with IODH.
First of all, make absolutely sure that you need a singleton, and that you want to provide "global-level" access to the singleton. I've found that in many cases clients of the singleton have no need to know that it is a singleton. Rather, they just need to get a service when they are instantiated.
Thus, regardless of how you obtain the singleton (if at all), consider changing the way your classes gain access to this object. While this means modifying constructors and changing "distribution changes", I've found that dependency injection frameworks reduce the cost. The DI framework can also then take care of singleton instantiation (e.g., Guice does that).
Aside from that. option 3 is the typical and most common (and thread safe) version that I'm familiar with. Option 1 is mostly for non-lazy initialization (not always acceptable). I've never seen 2 used.
Sample 1: Use if you don't need a lazy Singleton.
Sample 2: Never use - it gets confusing with too much classes. And an inner class just to hold one variable seems to be a bit unnecessary.
Sample 3: This is a lazy Singleton. Use it if you need it.