No, value objects do not need to be separate their news. More discussion here: http://misko.hevery.com/2008/09/30/to-new-or-not-to-new/

just read all the blogposts about this topic. Great stuff, I really liked those and I hope I remember to send them to my friends!

I have a question though, do you believe, that the separation of Object Construction and Logic should even be valid for standard library Objects such as Collections? If I need a queue for storing incoming Messages, would it be a violation to your rules to write
messageQueue = new Queue( );
inside the Constructor of my Class?

I would really like to hear your opinion on that. I suspect, that it is the best way to handle this, because the Queue (or any other Standard Library Object) is completly tied to my Class, even when Unit Testing.

Keep it up!

The cost of DI is arguments is a myth of not taking DI to its extreme: http://misko.hevery.com/2008/10/21/dependency-injection-myth-reference-passing/

What you have suggested at first looks like a good idea, and as long as you look at the class in isolation it is. The trouble becomes when you are testing house which needs kitchen. Since house will call the default constructor it is easy to cross the line and have the whole thing become the same as not having DI, so in practice this dose not work.

I agree, that DI is much more flexible way, but anything has it’s cost, and cost of using DI is lot of passed arguments.

What if we will build class both flexible (able to be isolated) and self-enough?
My example will be in PHP, not Java, excuse me for this, but I hope syntax not so different:

class House
{
private $kitchen;

public function __construct(IKitchen $Kitchen = null)
{
if (empty($Kitchen)) $Kitchen = new BaseKitchen();
else $this->kitchen = $Kitchen;
}
}

this class can be created with empty constructor, which can be very handy in many situations, and it will be decrease count of not necessary initializations of Kitchen object in code.
In other hand, this object can be created with special version of Kitchen (e.g. mock-object) in tests.

Please, comment, what do you think about this variant.

sure, if you are certain that they will always come together, than sure you can do that, but you will never be able to wire it differently. You can get away in few leafs sometimes with this strategy, but it should be rare, the default behavior should always me inject, unless you have a really good reason why it should be something different.

For instance:

private LocalDevice localDevice;

public BluetoothManager() throws BluetoothStateException {

localDevice = LocalDevice.getLocalDevice();

}

Given that LocalDevice is not within my domain and .getLocalDevice() contains logic along with creation of a LocalDevice object, what would you do? Inject it into my BluetoothManager and introduce logic into my object graph builder, or perhaps move localDevice = LocalDevice.getLocalDevice() to an init() method and agree to suffer creating a LocalDevice from within my business logic?