Constructor Overloading

Overloaded constructors are simply several constructors with different parameter lists on the same class. The compiler selects between them using the same rules it applies to overloaded methods, so the argument types and count have to be distinguishable at the call site. Two constructors may not have the same parameter types in the same order.

public class Main {
    public static void main(String[] args) {
        Money a = new Money(1050);
        Money b = new Money(10, 50);
        Money c = new Money("3.25");
        System.out.println(a);
        System.out.println(b);
        System.out.println(c);
    }
}

class Money {
    private final long minorUnits;
    Money(long minorUnits) { this.minorUnits = minorUnits; }
    Money(long whole, long cents) { this(whole * 100 + cents); }
    Money(String text) { this(Long.parseLong(text.replace(".", ""))); }
    public String toString() { return (minorUnits / 100) + "." + (minorUnits % 100); }
}

The output shows the three shapes working. The single-argument constructor takes an amount already expressed in minor units, the two-argument version combines units and cents, and the string version parses a textual amount. All three funnel into the one constructor that actually assigns the field, so there is a single place where the invariant of the class is established.

Delegation with this is the technique worth highlighting. It keeps the constructors thin and avoids repeating validation or conversion logic in each overload. The rule to remember is that a this call must be the first statement in the constructor, and that a constructor can delegate to at most one other constructor, so a cycle of delegating constructors is a compile error.

The trap to mention is overloading on similar types. If you have one constructor taking an int and another taking a long, a call with an int literal picks the int version, which may not be what the caller assumed. When two overloads behave differently for similar arguments, a factory method with a descriptive name is often clearer than another constructor.

Constructor overloading means giving a class several constructors that differ in their parameter lists, so callers can create an instance in different ways. It is the same idea as method overloading, applied to construction: the class provides convenience entry points that all funnel into one canonical way of building the object.

The reasons to do it are practical. Different callers have different amounts of information. A caller who knows only a title should not have to pass null for every other field, and a caller who knows everything should not be forced to use setters after construction. Overloads also let you accept a form that is more convenient for the caller, such as taking a string that you then parse.

The discipline that keeps it clean is that every overload ends up in the same place. Using this to delegate means validation and normalisation happen once, so two callers cannot end up with objects in different states just because they entered through different doors.

The cost is that the class grows a wider surface, and that too many similar overloads confuse callers. A handful of well-chosen constructors is the target; a dozen is a sign the class should have a builder or a factory instead.

The problem is that the compiler cannot catch the mistake. A constructor taking an int and an int has one signature, so it is written once, but the two parameters can be silently swapped at the call site and the code will still compile and run. If the first means width and the second means height, swapping them produces an object that is the wrong shape, and the bug surfaces much later, often in a rendering routine nobody remembers writing.

Two same-typed parameters in a business constructor is a design smell in itself, because it means the two values are interchangeable as far as the type system is concerned, yet they are not interchangeable in meaning.

The fix is to remove the ambiguity rather than document it. Give the parameters types that differ, so a width and a height cannot be confused, or take a single value object that names its own fields, so the caller cannot transpose anything. Where the values genuinely are the same type, use named factory methods such as fromWidthAndHeight, or make the constructor take an ordered collection with a documented meaning.

The interview angle is worth stating plainly: when the compiler cannot enforce the order, you have to enforce it in the design. A comment saying the order matters is the weakest possible defence, because it relies on every future caller reading it.