This question already has an answer here:

I read through a code example on github and instead of initializing the object using a constructor, they made every setter return the object itself to call it over and over again

See, constructors

DataSetIterator mnistTrain = new MnistDataSetIterator(batchSize, true, rngSeed);

vs chain of setters

 MultiLayerConfiguration conf = new NeuralNetConfiguration.Builder()
                .seed(rngSeed) //include a random seed for reproducibility
                // use stochastic gradient descent as an optimization algorithm
                .updater(new Nesterovs(0.006, 0.9))

What is considered better practice: constructor or their method?

marked as duplicate by gnat, jwenting, BobDalgleish, Community Apr 12 at 15:31

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • Is MultiLayerConfiguration the example you mean? – Laiv Apr 12 at 6:25
  • Yes just under the log "Build Mode..." – HashTableView Apr 12 at 6:31
  • Just as a clarification, usually the setter methods are not called on the object itself but on a object of the inner class Builder (full name NeuralNetConfiguration.Builder). The last call on this object (in your case list()) returns the actual object of type MultiLayerConfiguration. – findusl Apr 12 at 8:39

The difference is that if the constructor takes arguments, there is no way for you to leave any of them out. If objects are built1 by chained setters, you can choose which values to set. This can be an advantage (if you need the flexibility) or a disadvantage (if you want to prevent misuse of a complex class).

Therefore, neither method is better as such. All practices are used for some purpose, and "initializing objects" is such a ubiquitous task that it serves all kinds of purposes - some of those require consistent initialization, others require flexibility.

1: Via builder pattern as in the example


Having a dedicated class for the sole purpose of building another is called the builder pattern, and it is meant to alleviate problems involving complex instance creation, such as having a constructor take too many parameters or when the construction of an instance requires multiple steps.

If you do not use the builder pattern, that is not necessarily worse per se. Forcing a pattern to work when one is required is worse than not using a pattern when one would be useful in my humble opinion. However, it would seem that the builder pattern would make a good fit in your case, if the contrary means having several constructors accepting many parameters. Leave the constructors, and simply use a builder to call those constructors, so you don't have to deal with that logic throughout your program.

You should note however that this only works when many of the parameters being passed to the constructor have default parameters if left unspecified. An alternative solution could simply be to move these parameters out of the constructor and leave them as setters/getters in the class itself. In other words, you instantiate the instance passing only the minimum required information to the constructor and letting the getters/setters be the primary means for specifying additional information as required. Though again, this would be a good solution only if you have many optional parameters, most of which aren't normally specified.

In summary, if you're unsure which to use, try both and see which is preferable until you learn to get a feel for which is better in the future. Don't try to force a pattern when none is necessary.

Not the answer you're looking for? Browse other questions tagged or ask your own question.