such defense programing may come from C world where NullPointerExceptions are not handled well. In your example there is very little difference, if the program fails with assertion or with NPE a few lines down. If all other things were equal, I say defensive programing is a good thing, but things are not equal, since defensive programing makes it harder to write a tests. So the real question is, what is more valuable, defensive programing, which prove very little, or tests, which prove that your code works as expected. Of corse, it is not either or, and many times, you can have both defensive programing, and tests, but when they are at adds, I think testing should win.

it should be the responsibility of the house factory to make sure that the house is in the correct state. Also, your medium tests, should prove that it works as expected together.

Here’s my thoughts, and I agree with JF and Craig M above.

Defensive programming is a good thing. Putting assertions in the ctor makes the class robust, and can save you “maalox” moments down the road. Until the time comes to move the assertions, then I think it’s safe to keep it there. A good question to keep in mind when designing is…”what is the purpose of class?”

If the purpose of the class is to never have NULLs, then it makes perfect sense to put the assertion in the ctor. However, if NULLs are allowable, then it’s best to “spread the defense” by moving the assertions to the secure() function.

void secure()
{
Assert.notNull(door);
Assert.notNull(window);

door.lock();
window.close();
}

“Early In, Early Out”

I would also strongly avoid nulls, as they make things ugly.
http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare
Better use something like Null Object Pattern