Menu
I can't decide which approach is better for creating objects with a large number of fields (10+) (all mandatory) the constructor approach of the getter/setter. Constructor at least you enforce that all the fields are set. Java Beans easier to see which variables are being set instead of a huge list. The builder pattern DOES NOT seem suitable here as all the fields are mandatory and the builder requires you put all mandatory parameters in the builder constructor.
Thanks, D
719
You should not call getters and setters from the constructor. A constructor constructs the specific class in which it is defined. It is its job to initialise the fields because - well - nothing else will. The only way to guarantee initialising the fields is to assign them.
The constructors are used to initialize the instance variable of a class or, create objects. The setter/getter methods are used to assign/change and retrieve values of the instance variables of a class.
It can have as many constructors as you want, but it must have one no-argument constructor. Take into account that any java class without defined constructor will have a default no-argument constructor, but if you add any constructor with arguments, you need to explicitly define a no-argument constructor in this case.
If you want to create a instance with the value of int parameter other than 0, you can use constructor. if you are using setters, they are actualy methods, so if you have more than one setters then it is better to use constructor.
The better approach (imho) is to use some kind of builder:
MyClass a = new MyClassBuilder().blah("blah").foo("foo").doStuff().toMyClass(); where MyClass is still immutable but has a far more readable creation than a constructor with 10 arguments.
This is also called a fluent interface. Josh Bloch refers to this in Effective Java.
118
My first thought is to check whether your encapsulation model is correct. Having 10+ mandatory fields sounds like quite a lot and perhaps it makes more sense to have more finely-grained components in this scenario ?
Are some of these fields/parameters related ? Can they be combined into objects that make sense (e.g. x-coordinate and y-coordinate combined into a Point object etc.)
37
In his book Code Complete, Steve McConnell argues that no procedure should ever have more than a maximum of 6, maybe 7 arguments. Most of these statements are not just his opinion but backed by studies, e.g. of error rates related to code structure.
Clean Code by Robert Martin goes even further: He recommends 1 or 2 arguments, while 3 is already considered a "code smell". Personally, I think Clean Code is a bit extreme in places, but on the whole it makes some good arguments.
"A whole bunch of parameters" (however many that may be) bespeaks a "kitchen sink" design with lots of afterthoughts and little structure. It also makes maintenance more difficult and error prone; at the very least, it makes code hard to read.
All this makes for good reasons to think about cutting down on the number of parameters. Other answers have offered some practical suggestions.
20
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
