Start Method vs. Constructor Setup in Java

javaobject-orientedobject-oriented-design

The internal framework my company uses has a pretty pivotal Object that has a pattern of being instantiated as a member of a class with a no argument constructor but to be usable you have to call a start method. I understand that constructors are generally minimalist but at the same time why be able to construct an unusable object that you just have to call start on anyway?

Basically this

public class Someclass{
    FrameworkThingy thingy = new FrameworkThingy();

    //Framework auto runs this method as part of Spring beans
    public void startUpMethod() {
        thingy.start();
        // Why not just do the start stuff in the constructor?
    }
}

Best Answer

When I've seen this pattern in the past it's always been for one of the following reasons:

  1. Starting the class is an expensive operation. Leaving the starting logic in the constructor would slow down application bootstrapping/startup.
  2. Timing concerns. It could be that your class should never be started before another event in your application. So, instead of leaving the responsibility to Start to the class itself it may make more sense to hand that responsibility to a timing coordinator class.
  3. Stopping and Restarting are legitimate operations as well and only ever invoked explicitly. In this case, making Start be invoked implicitly in the constructor breaks the pattern and makes the class semantics a bit confusing.

Without any more specifics about your situation I can't really give you a more specific answer.

Related Topic