I wrote a class with "init" method. Should I call it from other class methods? Or leave it to the object user? (Code Design)

Question

I have a java class with an init method. It's different from the constructor. The constructor just initializes the variables/fields. The init method connects to a database and performs some verifications on the database + it kick starts a background thread which handles incoming requests.

If you wanna think of it in pseudo-code:

class SomeService:

    ...
    queue
    other fields
    ...

    public SomeService(Constructor input):
        initializes fields...

    public void init():
        connect to database and verify certain existence of a table
        start a thread
        initialized = true

    public String doSomething(Some Input):
        if !initialized: throw exception
        add job to queue to be picked up by the running thread

    public Integer doSomethingElse(Some Other Input):
        if !initialized: throw exception
        add job to queue to be picked up by the running thread

My question is, is it better to force the object user to call init before using the class methods? If you check the code above, any method will throw exception if it's called before init.

Benefits:

• This provides separation of concerns -- a method is only responsible of doing its job.

Downside:

• This, however, makes a bad class usability: what if init failed? the object user will always has to handle this. And might even try to call init before every other class method call.

The other option is call init at the beginning of every class method, internally.

Benefits:

• The class user doesn't need to worry about anything but getting his services done by the object.

Downside:

• Now a method isn't as good in terms of separation of concerns. It does its job after it tries to initialize the object.

Please note that the initialization procedure is a must before any other method does its job. Other methods won't be functional unless the object is initialized by calling init.

I believe it's obvious why I separated init from the constructor:

1. It's perfectly fine to have the object without it being initialized, and leave initialization for later.
2. A constructor shouldn't take long for initialization, which isn't the case. Connection to database, running multiple statements, and starting a thread. This isn't as snappy as just setting fields values.
3. If connection to database failed in a constructor, this will result in no object creation. This is bad behavior because the database can be available some other time after trial of object instantiation.

What I did is:

• Called init at the beginning of every method. To get the benefit of that.
• Availed init as public method to permit object caller for eager initialization.

So, what is it do you think is better? Call init at the beginning of every method? Leave it completely for the object user to handle it?

I tried to look it up but didn't find a fruitful answer.

I also tried to find in java 8 standard library if any class has init method, but couldn't find any. However, I found in java extension, Cipher class, which has init. and it works like approach#1 (leave it to the caller). That being said, this makes sense because its init takes user input, while mine doesn't.

I asked a chatgpt based bot and I got an answer that I should go with approach#2, calling init at the beginning of every method.

Answer 1

The init() method is a symptom, not the problem to be solved.

This class has some non-trivial initialization work to do. In a comment on another answer, you mentioned that a database connectivity hiccup shouldn't bring the whole thing crashing down. You need some robustness and fault tolerance in this class as well.

Since each method could throw an exception if the object is not initialized, callers must always test the object before calling a method. And when do they call init()? Can they call it more than once?

Laiv definitely has a good suggestion to hide this initialization logic. This does require a different design for the other methods. They need to work even when the database and background thread have not been initialized. You basically need an in-memory queue when the other methods are called before the object is fully initialized.

private void init():
    connect to database
    verify existence of a table
    start a thread
    initialized = true

    for params in doSomethingParams
        // replay method calls invoked before this object was initialized
        doSomething(params)

public String doSomething(Some Input):
    if !initialized
        init();
        doSomethingParams.add(Some Input);
    else
        someJobQueue.add(Some Input);

    return "what you would have normally returned";

Upon being initialized, loop through all of the "local" queues to push things into the newly initialized job queue. The point is, make sure this method succeeds even if the background thread or database is not available by pushing the parameters into a list. When those other resources are available, loop through that local list and call doSomething again, passing the parameters in the list, which essentially "replays" past method calls.

The main challenge here is that any call to your service can initiate an asynchronous operation, but if you are pushing things onto a queue that another thread uses, it's already asynchronous. Callers should assume this fact.

You can keep the init() method, but it would be private, and only methods in the service class will be calling it. This gives you lazy initialization, eliminates some unnecessary exceptions, and gives you the robustness you seek.

Answer 2

I'm availing init as public, but documenting the decoupling of init and the rest of the methods. If the user wants eager initialization, they can call init independently, otherwise, it's gonna be called internally if not initialized. So, the object user isn't forced or anything

The if sounds like you don't have use cases (or requirements) backing the decision of making init public. You made an assumption but looks like you haven't proved it to be true, so YAGNI applies. At the moment.

Note that we don't know if you are implementing a library or a piece of a framework. If that's the case, the more options you give the more use cases you cover. But having many options is not always better. The proof? Here you are with a list of pros and cons and trade-offs. Too many options can be confusing (which one is best? Which one do I need? I have to deal with trade-offs and I hate to do that, what if...).

I would suggest keeping it simple. Hide the method because it makes the consuming code likely to be cleaner, less verbose and more loosely coupled. Later, you can find other ways to implement eager initialization. I like @ErikEidt suggestion about doing so from the instance provider (factory, builder, IoC container, etc). The goal is to keep this "complexity" away from the consumer and located in a single place of failure (or source of truth depending on how you look at it).

Answer 3

I would recommend avoiding init-methods if at all possible. Getting an "object not initialized" is annoying, since it occurs at runtime. Moving errors to compile time makes types much easier to use, since your IDE should be able to tell you about problems even before you explicitly compile the code.

Using a "lazy initialization" pattern is preferable to forcing the user to call initexplicitly. But it still have the problem that any runtime errors may occur long after the class is created, and that might not be ideal since any incorrect parameters might not be apparent at that point.

Another option is to split the class into two:

1. A "factory" class with a single method that does any initialization and returns a service object.
2. The actual service type with all other methods. Once this has been created any initialization is complete, and the object ready to use.

This makes the initialization step visible to the user, while still ensuring it is done before the service is used.

Answer 4

An option to consider would be Lazy Initialization. With lazy init, we check to see if some value exists before we use it and if it doesn't, we take the time to spin it up. Really common on properties. In your case, the init could be tucked behind some private prop with any needed values provided to the constructor. It also avoids delaying construction and allows you to provide additional logic to handle re-tries, connectivity, or other work only when actually needed.

ex:

public class Foo {
    DbConn conn;
    private String connString;

    public Foo(String connString) {
        this.connString = connString;
    }

    DbConn getConn() {
        if (conn == null) conn = initDbConn();
        return conn;
    }

    private DbConn initDbConn() {
        return new DbConn(connString);
    }
}