Singleton Pattern, Configuration and Dependency Injection

Question

I am currently porting a C library to Java. The C library connects to an external device and provides functions to configure the device and receive data. The core of my design is a Connection class that encapsulates the connection to the device and provides the low-level C API mapping generated using JNA.

Since most of the C library doesn't translate that well into the OO-World of Java (Single header library containing 100+ functions) i have a couple of "Manager" classes that provide access to most of the functionality.

Creating more than one of these classes doesn't make sense, since the C library only manages one resource of everything (configuration, data-buffer, etc). So i want to implement the Singleton pattern for my Java classes (effectively also signaling the users of my new java library, that there is only ONE Manager object in the whole system).

Additionally i want to be able to configure these Manager classes using an external config file. I have never implemented a configuration utility before, so i don't really know where to put that.

Lastly ALL of my Manager classes need a reference to a Connection object.

So i need a design that allows me to:

Make my Java classes unique (Singleton Pattern)
Inject my Connection object
Configure my classes using a config file

Any ideas?

score 2 · Accepted Answer · edited May 23 '17 at 11:58

2

For the first two points, something like this would do the trick :

public class Connection{

    private static Connection instance = null;
    private String connectionString;

    protected Connection() {
    }

    public static Connection getInstance() {
       if(instance == null) {
          instance = new Connection();
       }
       return instance;
    }

    public void setConnectionString(String connectionString){
        this.connectionString = connectionString;
    }

    public String getConnectionString(){
        return this.connectionString;
    }
}

It's a classic example of a singleton in java. The constructor is protected, so you can't use the new keyword to instantiate it. Instead, you use it like this :

Connection con = Connection.getInstance();

getInstance() takes care of the instantiation and ensures only one instance of your singleton will ever exist. For instance, this :

    Connection con = Connection.getInstance();
    con.setConnectionString("foobar");

    Connection con2 = Connection.getInstance();
    System.out.println(con2.getConnectionString());

will print foobar

For the third point, I would refer you to this question where it has already been answered.

edited May 23 '17 at 11:58

Community

1
1

answered Jun 20 '16 at 18:03

A-y

793
5
16

I was actually talking about the connection being injected into another object, but i guess i can just use setter injection aswell. Where would you put the configuring (design-wise)? – Luca Fülbier Jun 20 '16 at 18:22
Probably a configuration class that read the config file and parses it to some kind of data structure. – A-y Jun 20 '16 at 18:27
And then configure the object using public getters and setters? – Luca Fülbier Jun 20 '16 at 18:28
1

You could use [this answer](http://stackoverflow.com/a/15976465/341278) for the configuration : – A-y Jun 20 '16 at 18:30
This is just what i needed. Thank you ;-) – Luca Fülbier Jun 20 '16 at 18:33

score 1 · Answer 2 · edited Jan 23 '19 at 14:48

public static Connection getInstance() {
       if(instance == null) {
          instance = new Connection();
       }
       return instance;
}

This implementation violates the singleton principle. Consider to use one of both lazy initialization methods:

with the synchronized key word public synchronized static Connection getInstance() { ... }

init-on-demand holder idiom.

public final class Connection {

    private static class Holder {
        private static final Connection INSTANCE = new Connection();
    }

    private Connection() {}
    public static Connection getInstance() { 
        return Holder.INSTANCE;
    }
}

To that, the init on demand holder idiom is a lazy synchronized Singleton and more performant than the first solution with the synchronized key word.

Singleton Pattern, Configuration and Dependency Injection

2 Answers2