Constructor Design

2 colleagues were in a “heated” argument over a design of constructors, which needed to have some form of the following parameters:

  • int code, String name, Serializable objParam
  • int code, String name, String xmlParam

The 3rd param could be either a String representing XML for an object, or a Serializable object. Both of them agreed there would be trouble differentiating between the two parameters, since Strings are serializable as well, and sometimes clients may want a String to be the Serializable param instead of XML.

To me it’s a non-issue, since the compiler is smart enough to use the String constructor if 3rd parameter was a String, and use the Serializable if I explicitly cast the String into Serializable (if I remember my signature-matching facts correctly).

One of them strongly pushed for a single constructor with 4 parameters, and passing in null for either the 3rd or 4th one. He argued this resolves ambiguity, as well as too many combinations of constructors available.

The other wishes to remove the optional 3rd parameter and use only 2 parameters. The 3rd parameter would be achieved using set methods.

Debate ensued, each bringing up points to support their views, such as cleanliness of API, ease of use, danger of forgetting to set the parameters, more parameters added next time. I wasn’t actually in the debate, I just happened to be the 3rd party in their chat window.

After a long while I suggested using static creational methods to differentiate between the 2 constructors. Something like Class.createXXXType() and Class.createYYYType() which I felt would be clear which “constructor” to refer to, non-ambiguity as well as stability of the instance created.

They didn’t take it very well too, and I left my suggestion as it is. There’s still no conclusion yet, they are still hesitating to call for a design review for this small matter.

Leave a Reply