How to design Java class(es) that can optionally function as Singleton?

Question

Here's the scenario:

public class A {    
    public A {}
    void doSomething() {
        // do something here...
    }
}

Right now, the class is setup where you can create multiple instances. But I also see a need where I might want to restrict the class to only one instance, i.e. Singleton class.

The problem is I'm not sure how to go about the design of accomplishing both goals: Multiple instances and one instance. It doesn't sound possible to do in just one class. I imagine I'll need to use a derived class, an abstract class, interface, something else, or some combination.

Should I create class A as a base class and create a derived class which functions as the singleton class?

Answer 1

Of course, the first thing should always be to question the necessity to use singletons. But sometimes, they are simply a pragmatic way to solve certain problems.

If so, the first thing to understand is: there is no solution that can "enforce" your requirements and prevent mis-use, but here is a "pattern" that helps a lot by turning "intentions" into "meaningful" code:

First, I have an interface that denotes the functionality:

interface WhateverService { void foo() }

Then, I have some impl for that:

class WhateverServiceImpl implements WhateverService {
  @Override
  void foo() { .... }

Now, if I need that thing to exist as singleton, I do

enum WhateverServiceProvider implements WhateverService {
  INSTANCE;
  private final WhateverService impl = new WhateverServiceImpl();
  @Override
  void foo() { impl.foo() }

and finally, some client code can do:

WhateverService service = WhateverServiceProvider.INSTANCE;
service.foo()

(but of course, you might not want to directly assign a service object, but you could use dependency injection here)

Such architectures give you:

1. A clear separation between the core functionality, its implementation and the singleton concept
2. Guaranteed singleton semantics (if there is one thing that Java enums are really good for ... then it is that: providing fool-proof singletons!)
3. Full "testability" (you see - when you just use the enum, without making it available as interface ... then you have a hard time mocking that object in client code - as you can't mock enums directly).

Update - regarding thread safety:

I am not sure what exactly you mean with "singleton concept".

But lets say this: it is guaranteed that there is exactly one INSTANCE object instantiated when you use enums like that, the Java language guarantees that. But: if several threads are turning to the enum, and calling foo() in parallel ... you are still dealing with all the potential problems around such scenarios. So, yes, enum "creation" is thread-safe; but what your code is doing ... is up to you. So is then locking or whatever else makes sense.

Answer 2

I think you should take a look at this question: Can a constructor in Java be private?

The Builder pattern described there could be a somewhat interesting solution:

// This is the class that will be produced by the builder
   public class NameOfClassBeingCreated {
      // ...

      // This is the builder object
      public static class Builder {
        // ...

        // Each builder has at least one "setter" function for choosing the
        // various different configuration options. These setters are used
        // to choose each of the various pieces of configuration independently.
        // It is pretty typical for these setter functions to return the builder
        // object, itself, so that the invocations can be chained together as in:
        //
        //     return NameOfClassBeingCreated
        //         .newBuilder()
        //         .setOption1(option1)
        //         .setOption3(option3)
        //         .build();
        //
        // Note that any subset (or none) of these setters may actually be invoked
        // when code uses the builer to construct the object in question.
        public Builder setOption1(Option1Type option1) {
           // ...
           return this;
        }

        public Builder setOption2(Option2Type option2) {
           // ...
           return this;
        }

        // ...

        public Builder setOptionN(OptionNType optionN) {
           // ...
           return this;
        }

        // ...

        // Every builder must have a method that builds the object.
        public NameOfClassBeingCreated build() {
           // ...
        }

        // The Builder is typically not constructible directly
        // in order to force construction through "newBuilder".
        // See the documentation of "newBuilder" for an explanation.
        private Builder() {}
      }

      // Constructs an instance of the builder object. This could
      // take parameters if a subset of the parameters are required.
      // This method is used instead of using "new Builder()" to make
      // the interface for using this less awkward in the presence
      // of method chaining. E.g., doing "(new Foo.Builder()).build()"
      // is a little more awkward than "Foo.newBuilder().build()".
      public static Builder newBuilder() {
         return new Builder();
      }

      // ...

      // There is typically just one constructor for the class being
      // constructed that is private so that it may only be invoked
      // by the Builder's "build()" function. The use of the builder
      // allows for the class's actual constructor to be simplified.
      private NameOfClassBeingCreated(
          Option1Type option1,
          Option2Type option2,
          // ...
          OptionNType optionN) {
        // ...
      }
   }

Link for reference: https://www.michaelsafyan.com/tech/design/patterns/builder

Answer 3

I am not sure that this is what you are looking for, but you can use Factory pattern. Create 2 factories, one will always return the same singleton, while the other one will create a new A object each time.

Factory singletonFactory = new SingetonFactory();
Factory prototypeFactory = new PrototypeFactory();

A a = singletonFactory.createA();
A b = singletonFactory.createA();
System.out.println(a == b); // true

A c = prototypeFactory.createA();
A d = prototypeFactory.createA();
System.out.println(c == d); // false


class A {
    private A() {}
    void doSomething() { /* do something here... */}
}

interface Factory {
    A createA();
}

class SingetonFactory implements Factory {
    private final A singleton = new A();

    public A createA() {
        return singleton;
    }
}

class PrototypeFactory implements Factory {
    public A createA() {
        return new A();
    }
}