Constructor overloading in Java - best practice

Gregory Mostizky :

It really depends on the kind of classes as not all classes are created equal.\n\nAs general guideline I would suggest 2 options:\n\n\nFor value & immutable classes (Exception, Integer, DTOs and such) use single primary constructor as suggested in above answer\nFor everything else (session beans, services, mutable objects, JPA & JAXB entities and so on) use default constructor only with sensible defaults on all the properties so it can be used without additional configuration\n",

2009-07-26T09:41:21

Spoike :

While there are no \"official guidelines\" I follow the principle of KISS and DRY. Make the overloaded constructors as simple as possible, and the simplest way is that they only call this(...). That way you only need to check and handle the parameters once and only once.\n\npublic class Simple {\n\n public Simple() {\n this(null);\n }\n\n public Simple(Resource r) {\n this(r, null);\n }\n\n public Simple(Resource r1, Resource r2) {\n // Guard statements, initialize resources or throw exceptions if\n // the resources are wrong\n if (r1 == null) {\n r1 = new Resource();\n }\n if (r2 == null) {\n r2 = new Resource();\n }\n\n // do whatever with resources\n }\n\n}\n\n\nFrom a unit testing standpoint, it'll become easy to test the class since you can put in the resources into it. If the class has many resources (or collaborators as some OO-geeks call it), consider one of these two things:\n\nMake a parameter class\n\npublic class SimpleParams {\n Resource r1;\n Resource r2;\n // Imagine there are setters and getters here but I'm too lazy \n // to write it out. you can make it the parameter class \n // \"immutable\" if you don't have setters and only set the \n // resources through the SimpleParams constructor\n}\n\n\nThe constructor in Simple only either needs to split the SimpleParams parameter: \n\npublic Simple(SimpleParams params) {\n this(params.getR1(), params.getR2());\n}\n\n\n…or make SimpleParams an attribute:\n\npublic Simple(Resource r1, Resource r2) {\n this(new SimpleParams(r1, r2));\n}\n\npublic Simple(SimpleParams params) {\n this.params = params;\n}\n\n\nMake a factory class\n\nMake a factory class that initializes the resources for you, which is favorable if initializing the resources is a bit difficult:\n\npublic interface ResourceFactory {\n public Resource createR1();\n public Resource createR2();\n}\n\n\nThe constructor is then done in the same manner as with the parameter class:\n\npublic Simple(ResourceFactory factory) {\n this(factory.createR1(), factory.createR2());\n} \n\n\nMake a combination of both\n\nYeah... you can mix and match both ways depending on what is easier for you at the time. Parameter classes and simple factory classes are pretty much the same thing considering the Simple class that they're used the same way.",

2010-04-13T19:02:37

oxbow_lakes :

I think the best practice is to have single primary constructor to which the overloaded constructors refer to by calling this() with the relevant parameter defaults. The reason for this is that it makes it much clearer what is the constructed state of the object is - really you can think of the primary constructor as the only real constructor, the others just delegate to it\n\nOne example of this might be JTable - the primary constructor takes a TableModel (plus column and selection models) and the other constructors call this primary constructor.\n\nFor subclasses where the superclass already has overloaded constructors, I would tend to assume that it is reasonable to treat any of the parent class's constructors as primary and think it is perfectly legitimate not to have a single primary constructor. For example,when extending Exception, I often provide 3 constructors, one taking just a String message, one taking a Throwable cause and the other taking both. Each of these constructors calls super directly.",

2009-07-25T14:16:20

Thorbjørn Ravn Andersen :

If you have a very complex class with a lot of options of which only some combinations are valid, consider using a Builder. Works very well both codewise but also logically.\n\nThe Builder is a nested class with methods only designed to set fields, and then the ComplexClass constructor only takes such a Builder as an argument. \n\n\n\nEdit: The ComplexClass constructor can ensure that the state in the Builder is valid. This is very hard to do if you just use setters on ComplexClass.",

2009-07-25T16:52:03