Java constructor design

Question

I was reading an open-source code, and there was a constructor designed like this:

public class FeatureSequence2FeatureVector extends Pipe implements Serializable
{
    boolean binary;

    public FeatureSequence2FeatureVector (boolean binary)
    {
       this.binary = binary;
     }

    public FeatureSequence2FeatureVector ()
    {
       this (false);
    }
 }

This may be just a trivial preference matter, but what I would do is like this:

public class FeatureSequence2FeatureVector extends Pipe implements Serializable
 {
    boolean binary = false;

    public FeatureSequence2FeatureVector (boolean binary)
    {
       this.binary = binary;
     }
     public FeatureSequence2FeatureVector ()
     {
     }
 }

Is there any possible negative outcome by assigning an initial value for class variables? Would the two ways be almost equally preferred?

instance boolean variable is by default initialized with `false` value. There is no need of `this (false);` and `binary = false;` — Braj, Aug 12 '14 at 19:44
oh okay so maybe initializing part would not even be necessary although I would still put it for clarity. — pandagrammer, Aug 12 '14 at 19:45
Possible duplicate of http://stackoverflow.com/questions/804589/use-of-initializers-vs-constructors-in-java. — Dici, Aug 12 '14 at 19:45
But my question was not really about whether what the initial value of boolean variable is, but more about the way of designing constructors. — pandagrammer, Aug 12 '14 at 19:47
If the instance variable were `final` then your version would not compile, it is generally good practice to mark all instance variables that are constant as `final`. Otherwise the other version makes the intent clearer. — Boris the Spider, Aug 12 '14 at 19:47
@xgeorgekx : There's no link between this question and the one you are talking about (which is about Boolean wrapper). — Dici, Aug 12 '14 at 19:48
@pandagrammer : I think the link I posted answers to your question, or at least deals with the same subject. — Dici, Aug 12 '14 at 19:48

score 4 · Accepted Answer · edited May 23 '17 at 10:26

These two ways are not equally preferred.

The original way makes sure that all initialization goes through a primary constructor. The second way allows different paths for initializing an object.

In your example it's pretty trivial. But with the second way one constructor could be modified to do something different from how the other constructor did things, whereupon how your objects are initialized depends on which constructor was chosen.

This question shows a situation where allowing different paths caused trouble.

score 1 · Answer 2 · answered Aug 12 '14 at 19:51

One reason I've seen developers do this is for maintainability and future-proofing.

Let's break it down into a different application:

public void foo() {
  this.foo(1);
}

public void foo(int a) {
  this.foo(a, 2, 3);
}

public void foo(int a, int b, int c) {
  // ...
}

foo is assumed to do the exact, or a similar, operation - regardless of the overload. However, what if that functionality were to change? In your example, you'd have to change the functionality for both versions, whereas in the above example, only foo(int, int, int) would have to be changed.

Future-proofing is something that is taken into account in the design of an API, and the above design pattern is adopted frequently due to the ability to maintain one block of code versus 2 or 3 (or however many overloads you have).

Constructors are no different, other than that they are invoked with this(...).

In that case foo would probably be final to avoid it to be overrided by the inherited classes, but I think you have a good point. foo can also be replaced by a private (or not) constructor which every other constructor has to call (kind of a main constructor). — Dici, Aug 12 '14 at 19:54

Java constructor design

2 Answers2

Linked