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 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.
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 you write many constructors that make 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.