In this idiom, the constructor does all the work - there is no separate method that you call. This idiom usually occurs when you have a MethodObject:

	new Method_Object (args...);

'''Disadvantages'''

	* Return value must be in the argument list.
	* Subclassing is a dicey proposition.
	* You will confuse the reader - few developers use this idiom because of its many disadvantages
	* It goes against ComposedMethod. ''How?'' Constructing an object is one identifiable task, performing a piece of work is typically another.
	* Side effects can be invoked inadvertently by declaring/initializing objects
	* Refactoring several constructors into one and using the created object might fail
	* Refactoring a temporary object into several method calls might fail
	* Can't pass parameters to COM constructors.

'''Advantage'''

	* Looks more like a method call, which is a strong clue to the reader that the code is invoking a MethodObject (although not as much as a method named "invoke").

See Also: ThrowawayObject
Opposite of: InitializationSeparateFromConstruction
----
'''True Stories'''
----
An example of why this is can be a bad idea...

I have used a user-space thread library for C++ in which threads were created by deriving from a thread base-class. The base class constructor did some magic to create a new processor context in which continue constructing the object, so one implemented the body of the thread in the derived class constructor. 

The drawback was that one could not have inheritance hierarchies that were more than one level deep and you could not invoke other initialization methods on a thread object after construction but before it was spawned.

-- NatPryce
----
If you use inheritance hierarchies with constructors that connect objects
to other parts of framework, you often need "before" and "after" hooks.
These hooks should be called from leaf classes. If a class is a base for another
class, but not abstract, it may need two constructors: one intended for
derived classes, and another when used as a concrete class.

All this complexity hurts, so its best to apply the DontDoThat principle, and use factories, builders, etc. I have a couple of nascent patterns on top of the GOF ones about how to organize these, especially for component-based systems, but they have not gelled yet.

Incidentally, such hierarchies are often a good indication that the implementors have used inheritance where composition would work better.

-- AamodSane
----
Borland's DelphiLanguage provides after-construction and before-destruction virtual methods for all classes. I thought it was rather neat, but I couldn't see much use for it until now. (The reason given in the manual is to allow constructors to call the proper virtual methods after the object is *fully* constructed.)  With DelphiLanguage's implementation, one can override the after-construction method without changing the base class constructor. -- CliffordAdams
----
One of the worst C++ systems I ever had to work on used this idiom, and it made it (literally) twenty times bigger than it needed to be. Each side effect (like sending a few bytes to a remote system) was implemented as at least six layers of nested constructors. It was awful to debug or understand as nothing could return a reasonable return value. It was also especially dangerous as many of the constructors took place at initialization of static data time (before 'main'), which is before some debuggers and profilers etc. get properly started.

Since then I've steered very clear of this idiom, in C, C++ and Java. -- FrankCarver
----
Constructors doing the work are hard to unit test.	So other things equal, you'll get lower code quality. - DaveVanBuren
----
CategoryCpp CategoryJava