Comments on: Flaw: Constructor does Real Work

By: miluch

miluch — Wed, 06 Jan 2010 08:50:29 +0000

Hi
Thanks for a link to your post. I have read it 3 times and I am still not convinced.
Hopefully, after reading comments of this post i can see that I am not the only one who disagrees with you.
The thing i do not understand the most is
“Now there is a difference if the API is meant for my internal consumption or is part of an external API”
How can you guarantee that none of your colleagues will call your “internal consumption API” ? Use access level modifiers ?

I can agree with guys who proposed using some stubs/mocks to pass to House constructor.
I would do the same in this case ( using DI would be even better) but in my triangle scenario it is not about collaborators validation
but validating internal consistency of object.

By: misko

misko — Wed, 06 Jan 2010 00:32:09 +0000

see: http://misko.hevery.com/2009/02/09/to-assert-or-not-to-assert/

By: miluch

miluch — Tue, 05 Jan 2010 19:48:20 +0000

I am wondering what’s your opinion about checking invariants in constructor.
Let’s say you want to create triangle object, feeding it’s constructor with degrees of 3 angles.

Triangle(int angle1, int angle2, int angle3)

For triangle all interior angles total to 180 degrees.
Since I truly believe that objects should be responsible for ensuring validity of its state, checking if sum of user provided angles equals to 180 should be done in constructor – you would end up having some conditional logic in your constructor…

If invariant is violated i would throw IllegalArgumentException…

This approach seems to be very attractive – you will always work with valid triangles, but it kills testability:
To test any of triangle behavior (for example checking if triangle is right-angled) you first need to instantiate it feeding it with correct angle values.
For triangle example it does not seem to be the case, but in more complex scenarios instantiating object to be tested can be quite hard – not because of its hard coded collaborators but because of its invariants.

By: Einführung in TDD & Clean Code Talks | geekcloud.org

Einführung in TDD & Clean Code Talks | geekcloud.org — Sun, 22 Nov 2009 15:07:57 +0000

[...] Flaw #1: Constructor does Real Work [...]

By: Trimming the fat around constructors « Curly Braces

Trimming the fat around constructors « Curly Braces — Mon, 16 Nov 2009 09:44:24 +0000

[...] 1. Misko Hevery – The Testability Explorer Blog [...]

By: Giorgio Sironi

Giorgio Sironi — Wed, 07 Oct 2009 18:56:20 +0000

Bill,
in my opinion you should not do work in the constructor of a client, and the possible cases are two:
- the Client needs a collaborator with the same lifecycle. So pass it as an argument of the constructor of the Client.
- the Clicnt needs to create an object at a certain point of execution, in a method. So pass in a Factory in the Client’s constructor.

By: Bill Sanders

Bill Sanders — Sun, 04 Oct 2009 09:24:05 +0000

Does any of this apply to a Client class? (I use the term ‘Client’ in the way GoF does.) Following the principle of having the constructor do no real work has solved all kinds of problems in my patterns, but when I go to call the design, I have to use the constructor method in the Client to instantiate objects. In other words, the constructor in the Client does real work.

Thanks,
Bill

By: Wicket is complicated « Lumpynose’s Weblog

Wicket is complicated « Lumpynose’s Weblog — Tue, 22 Sep 2009 06:35:30 +0000

[...] Sometimes in the constructor they call methods on the dao. That just seems wrong. For why, see this article by Miško Hevery. [...]

By: MeBigFatGuy

MeBigFatGuy — Fri, 11 Sep 2009 21:15:29 +0000

Kicking off a thread in a ctor is no good either.

By: Nicolas

Nicolas — Mon, 06 Jul 2009 20:00:27 +0000

All this stuff seems biased to Java, not general guidelines.

Nothing is “injectable” in C++, and you can’t always subclass to make a mock (classes don’t use virtual methods unless really needed).