When to call the constructor and when to call the method in Java?

Question

I am struggling to fully understand the usage of constructors in Java.

What I have learned so far about constructors is the following:

• same name as class
• abbreviation ctor
• overloading
• no return type
• create an object of a class
• every class has a default constructor

When for example a string has to be returned from a class that needs to be called then a method could be created, i.e. a constructor will not be sufficient as this will not return anything.

Attempt to answer the question

In order to explain what I mean, I have created a class with two constructors and two methods that return a string.

public class HelloWorldConstructor {
    public HelloWorldConstructor() { }

    public HelloWorldConstructor(String a) {
        saySomething(a);
    }

    public HelloWorldConstructor(String a, String b) {
        saySomething(a, b);
    }

    void saySomething(String a) {
        System.out.println(a);
    }

    void saySomething(String a, String b) {
        System.out.println(a + ", " + b);
    }
}

Option 1

It is possible to return a string by calling the method that resides in the class.

public class CallConstructor {
    public static void main(String[] args) {
        HelloWorldConstructor hwc = new HelloWorldConstructor();

        hwc.saySomething("allo");
        hwc.saySomething("allo", "allo");
    }
}

returns:

allo
allo, allo

Option 2

It is also possible to return a string by calling the constructor directly.

public class CallConstructor2 {
    public static void main(String[] args) {
        new HelloWorldConstructor("allo");
        new HelloWorldConstructor("allo", "allo");
    }
}

returns the same as option 1.

Discussion

When option 2 is chosen, then two objects have to be created instead of one as depicted by option 1, but when to choose option 2 and when option 1? In this case I think it is better to choose option 1 as one object will be created, but option 2 could be suitable when other circumstances are applicable.

Using Constructors in Java

The constructor in the example just gives an initial value to class members.

https://stackoverflow.com/a/19941847/2777965

Constructors are used to initialize the instances of your classes. You use a constructor to create new objects often with parameters specifying the initial state or other important information about the object

After reading about theory and Q&As about constructors I am struggling to fully understand them. I know how to call a constructor and how to call a method, but I cannot rationalize this.

• A constructor has to be called directly when ...
• Constructor overloading will be done when ...
• Methods will be called directly by calling the default constructor when ...

Answer 1

You call a constructor when you want to create a new object instance. For example if you have a class Button, then you call the constructor if you want to create a new Button instance.

If you don't need a new object, then don't use a constructor. In your example you just use the constructor as a convoluted way of calling a method, but you don't actually use the created object (the result of the new-expression) for anything. This is a clear hint that you don't need to call a constructor. If you made saySomething static you would not need to call any constructors.

The reason for your confusion is probably that the HelloWorldConstructor class does not really have any purpose beyond writing output. Therefore it is not obvious whether you should have one or two instances of it. In reality you don't need any instance at all.

Answer 2

same name as class

True, in java

abbreviation ctor

True

overloading

True

no return type

Well... no explicit return. A ctor always has an implicit return type. The class is the type. A ctor, when used with the new keyword, returns the object it creates and that object's type is the class. Thankfully, when you define a ctor you don't have to say the class name yet again.

create an object of a class

That is what it does.

every class has a default constructor

Well... no. As wikipedia puts it:

In both Java and C#, a "default constructor" refers to a nullary constructor that is automatically generated by the compiler if no constructors have been defined for the class. The default constructor implicitly calls the superclass's nullary constructor, then executes an empty body.

Wikipedia: Default Constructor

So no, not every class has a default constructor. Every class will have some constructor. It only has the default constructor if you don't define one for it explicitly.

BTW, "nullary constructor" is a fancy way to say a no argument constructor.

When for example a string has to be returned from a class that needs to be called then a method could be created, i.e. a constructor will not be sufficient as this will not return anything.

Ugg. Look, there are constructors that "return" strings just fine. They all live in the String class.

In order to explain what I mean, I have created a class with two constructors and two methods that return a string.

No you haven't. Outputting is not returning. Your constructors don't return strings. They "return" objects of the HelloWorldConstructor type.

Which is why this compiles:

HelloWorldConstructor hwc = new HelloWorldConstructor();

Option 1: it is possible to return a string by calling the method that resides in the class.

It would be if your methods returned strings. They return void. Again, outputting is not returning.

Option 2: It is also possible to return a string by calling the constructor directly.

You mean output a string. Yes you can make a constructor do other things besides simply construct the object, as God intended. That doesn't mean it's a good idea.

When option 2 is chosen, then two objects have to be created instead of one as depicted by option 1, but when to choose option 2 and when option 1? In this case I think it is better to choose option 1 as one object will be created, but option 2 could be suitable when other circumstances are applicable.

Construction of objects and use of objects should happen in seperate places. Mashing them together like this just makes a mess.

A constructor has to be called directly when ...

When you're constructing the object. Put it in a handy variable and pass it to something that would use it.

Constructor overloading will be done when ...

... you can't make up your mind what your object should depend on. If you can think of many ways to build the same object then you write many constructors that build it those many ways.

Methods will be called directly by calling the default constructor when ...

Sorry this just makes no sense. You call methods on objects when it's time to use them. You call constructors (default or not) when it's time to build them.

Again, you do not have to build and use at the same time. In fact it's usually better if you don't. Polymorphism only works when you don't know exactly what you're talking to.

When to call the constructor and when to call the method in Java?

Best answer I have for this comes from Dependency Injection which says to do your construction as high up the call stack as you can. Which pretty much means do construction in main. Personally I don't mind if you use some Creational Patterns that take you out of main for a bit but keep the behavior code away from there.

Answer 3

Our job as programmers is to offer automation to various real-world domains — doing that often requires us to represent various domain concepts, their relationships, and their behaviors or capabilities.

In programming, we represent various concepts, relationships, and behaviors using the programming language's capabilities for defining abstractions. Abstractions, because while on the one hand they model some domain concepts, relationships, and behaviors, yet on the other hand, they have internal implementation details (e.g. state & algorithms) that we prefer to shield from the consuming client programmer (often ourselves) to reduce complexity and ease programmer burdens.

The class is one mechanism for creating abstraction. It allows bundling of methods and state in a single entity that can be manipulated by a consuming client programmer.

Importantly, the class construct allows for customizable instances. Instance customization is usually done through parameters passed to the constructors. Constructors offer the capabilities to bind an instance to certain values or certain other objects.

Once constructed, an instance can now be used to access behaviors and relationships of the concept, by using its methods.

Typical of using abstractions, we separate concerns, and create objects in one place and use them in others: object creation represents a milestone of some sorts, and once created, an instance can be handed off to be used by some other consuming client programmer, capable of working with different object instances of the same type (class or interface) regardless of how they were created.

---

Your class HelloWorldConstructor, is obviously an just an arbitrary sample for purposes of your question — we wouldn't usually name a class after the ability to construct, but after the abstraction that its instances represent.

This class is also overly simplistic in that it doesn't have any state. (While it is sometimes reasonable to have an instance without state, useful scenarios of that usually involve multiple different classes that are sharing some interface (or base class).) Without state, the constructor is not binding anything — to put it another way, the constructor is not participating in creating a customized instance.

Still, all that being said, your option 1 is more in the style of object oriented programming than the other because it creates an instance and later uses it — even though it does this in immediately adjacent lines of code.

Your option 2 is effectively a procedural form of programming (i.e. not OOP) since you're doing all the work in the constructor and then throwing away the instance that's been created.

---

A typical scenario is to use the constructor to customize an instance, and then, once created, hand the customized instance off to some more generic code that can work with any instance of that class. That more generic code then carries out some useful behaviors with the customized instance.

For example, add a parameter to the constructor to take a name as a string. Now the contructor's job is merely to capture that name.

public class SayHi {
    private String name;

    public SayHi(String toWhom) {
        name = toWhom;  // capture customization parameter
    }

    public void saySomething(String a) {
        System.out.println(name + ": " + a);
    }
}

We can now create differently customized instances new SayHi("Erik") ... new SayHi("030"), and use those different instances with the same code.

Answer 4

• A constructor has to be called directly when ...

Never.

You invoke a constructor by using the new key word and the JVM will invoke the constructor for you.

• Constructor overloading will be done when ...

You write brittle code.

Constructor overloading means that you have more than one constructor in the same class.

Constructors should set (final) instance variables (aka members or fields) of the object (and nothing else except simple validations). Since different constructors must have different parameter types or different parameter count the consequence of having them is one of four cases:

1. You only set the the members having relates parameters passed in into the individual ctor.

   The result of this is that you have to assign null to members not relating to a parameter of the current ctor. This usually means that you have an invalid object forcing you to throw null-checks throughout your code.

2. You assign some default values to members not relating to a parameter of the current ctor or call another ctor in this class passing the current parameters and those default values. (constructor chaining)

   The consequence of this is that you hide the real dependencies of your class from the user. Users of your class may be confused.

3. You "calculate" the missing values.

   Ctors should not do any calculation, just initializing the members. Anything else will make your class hard to reuse.

4. You acquire missing values by accessing static methods in other classes (singeltons by any chance...)

   This is the worst case since it creates an unbreakable hidden coupling to this other (singeton) class.

As a rule of thumb: A class should have one ctor only.

• Methods will be called directly by calling the default constructor when ...

Never.

A constructor (as already written) only assigns values to members. It does not calculate anything and therefore it should not call any other method within the class.

---

As you become experienced you might find valid reasons to brake these rules, but as a beginner you should stick to them.