使用单例模式对 Java 中的大型泛型类有好处吗？

Question

I'm new to Generics and the Singleton pattern in Java. I have the following questions:

• Is a Generic class compatible with the Singleton Pattern, namely having a static instance?

• If so, I have the following Generic class that I want to convert to a Singleton. What is the best practice?

• (Beginner question) Is there a good way to de-generify an instance of the class in runtime? passing the class as parameter in getInstance()?

class GenFooSingleton <T>
{
    private T t;

    // Prevent direct instantiation
    private GenFooSingleton(T o){
        this.t = o;
    }

    private static GenFooSingleton INSTANCE = null;

    // Returns the single instance of this class, creating it if necessary
    static synchronized <T> GenFooSingleton<T> getInstance(T tClass)
    {
        if (INSTANCE == null)
        {
            INSTANCE = new GenFooSingleton<>(tClass);
        }
        return INSTANCE;
    }

}

Edit

My use case of a Generic with Singleton:

1. Why Generic? First let's say I have the the following Singleton Repository for one type of data to begin with, the following example is from what I learned in the googlesamples/android-architecture

class FooRepository implements FooDatasource
{

    private final FooDatasource local;
    private final FooDatasource remote;
    Map<String, Foo> mCahcedItems;

    // Prevent direct instantiation
    private FooRepository(FooDatasource remote, FooDatasource local){
        this.remote = remote;
        this.local = local;
    }

    private static FooRepository INSTANCE = null;

    // Returns the single instance of this class, creating it if necessary
    public static synchronized FooRepository getInstance(FooDatasource remote, FooDatasource local)
    {
        if (INSTANCE == null)
        {
            new FooRepository(remote,local);
        }
        return INSTANCE;
    }

    // implement CRUD methods
    @Override
    public Flowable<List<Foo>> getFoos(){
        // Update the mCahcedItems with the list of Foos
        // return a list of Foos and syncing between the local and remote datasources...For brevity the bunch of Rxjava implementation is omitted.  
    }

    @Override
    public Flowable<Optional<Foo>> getFoo(){
        // Update the mCahcedItems with Foo
        //...
    }
}

But I can see I would have to create repository for each data type. (Foo, Baa, Daa, etc) where the CURD logic is essentially the same and each instance. So naturally I'm thinking of making the repository a Generic one.

2. Why Singleton? Without using the Singleton pattern, each new instance would start a complete new reload the in-memory cache, which means new local database queries. In developing for mobile and memory constrained devices (Android Apps), that would amount to unnecessary and I/O calls each time the device changes configuration/rotation. The mere thought of that just flags a huge performance problem that I would have to deal with. Therefore, I think A globally accessible single instance that is only lazily instantiated is a plus.

My attempt So I set out to create generic versions of both the Repository and Datasource interface, and have each data type provide the concrete implementation when they implement the Datasource interface, like below:

class FooDatasource implements GenericDatasource<Foo>
{
    //...
}

class BarDatasource implements GenericDatasource<Bar>
{
    //...and so on and so forth
}

Update

My current approach is a singleton pattern with Generic instances can be better managed with Dependency injection using Dagger 2, for both Java and specifically Android dev.

Answer 1

Is a Generic class compatible with the Singleton Pattern, namely having a static instance?

No, it won't work like that, static fields exist only once, static inheritance doesn't exist in Java. But there are many different ways to implement a singleton.

If so, I have the following Generic class that I want to convert to a Singleton. What is the best practice?

Don't do it. Singleton is an antipattern, mainly because it's horrible for testing purposes. Instead, use a container (Spring, Guice, EJB etc.) to manage singletons for you, making sure only one instance exists. Start by reading about the Dependency Inversion Principle and Inversion of Control .

(Beginner question) Is there a good way to de-generify an instance of the class in runtime? passing the class as parameter in getInstance()?

Yes, passing the class to getInstance would actually make this a bit nicer, especially if you use a class-to-instance-Map internally ( Guava has such a type )

Answer 2

1. Since the singleton pattern tries to guarantee only one living instance of a given class at any time, it's not very compatible with the idea of a versatile class that can accept or produce different results depending on its current generic type. For generics to be any useful, you need to be able to create different flavors of the same type (usual exemple: a List of String and a List of Integer)
2. N/A
3. If you are passing a parameter to the getInstance of a singleton, then you are not really wanting a singleton but a factory. A singleton can only be non parameterized, or else the first call freezes the context.

Do not abuse of singleton. They are the first pattern you may try to implement, because it's the first in every book, but it's almost always at least useless, at most a performance bottleneck and a bad design decision (not very OO)

EDIT:

you assumption that each new instance couldn't share the same cache is basically wrong, for two reasons:

1. not using a Singleton does not forces you to use several instances of the same type. It just allows you to do so, as well as enabling inheritance (which the singleton simply cann't). If you use Spring and a singleton-scoped bean (the default), then your repository exists only once in memory - even if it does not implement the singleton pattern as described in the books - and is shared between all consummers (thus only one cache). This can be accomplished without spring too, just use some kind of factory or registry.
2. caching with an hashmap in your class is a bit fishy, too. Caching is an implementation detail and you should not try to implement it in this way (you will end up eating the whole memory quite easily, at least, use WeakHashMap instead - or the Guava version, using CacheBuilder). You could also declare your cache as static so it will only exist once in memory. Modern applications treat caching as an aspect , like transactions for example. It should not leak to your code. For example, look at ehcache, redis, terracotta, etc. they all implement the JSR-107 and are configured directly on your method prototype, with some annotation (@Cacheable, etc.). Ho and caching usually goes to the service layer - you do not cache the state of the db, you cache the responses sent to the users after processing of the business logic (even if this rule is not absolutely strict)

The singleton also has a very big problem: it is directly responsible to instantiate the object, that is, direct use of the new keyword. This is a pain, as you can not change the concret type of the implementation at runtime (for testing purpose, or any other use). Look at the factory/factory method pattern to see a better way to change the type at runtime.

What you can do is having an abstract base class, generified, that your concret dao will extend (but those will not be generic). Something like this:

abstract class AbstractDao<ID, T> {
  private Class type;
  protected AbstractDao(Class type) {
      this.type = type;
  }
  void save(T entity) {
    // save an entity
  }

  T get(ID pkey) { /* get an entity */}
  ...
}

public class DaoX extends AbstractDao<Long, X> {
  DaoX() {
    super(X.class)
  }
  /* Empty! or only methods applicable for X */
}
public class DaoY extends AbstractDao<Integer, Y> {
  DaoY() {
    super(Y.class)
  }
  /* Empty! or only methods applicable for Y */
}

In this case you are not duplicating any code.