In terms of instantiation, you are just moving the creation logic somewhere else but that is the whole point. The business of creating objects is separated from the normal work of the objects themselves. That is the specific goal. If you can’t find any benefit in that then DI is not for you.

The body would take in various subsystems, as would the engine and chassis.

Anything with more than a handful of parameters is just a pain to use.

It all depends, pun intended, on what your application has to actually DO with a “car”.

Are you really suggesting that the Car’s constructor takes an instance of: Engine, Wheels, Seats, Drivetrain, ExhaustSystem, Electrics, etc. ?

What does the object that instantiates the Car look like?

Whilst pushing the decision up the chain can help, at the end of the day we need to write perfomant apps that can be maintained long term by people that didn’t write the original system. 90% of the time it’s gonna be fine to let the engine decide what type of pistons it needs. We just need to be able to override the default choice (usually for testing parts in isolation).

Regards,

Rob….

Seams to me it’s top heavy even for larger application development; my opinion is that you can achieve much the same effect solely with Factories – in which case you simply swap out factories.

I am of the feeling we need to streamline an applications foot print and most DI solutions are additional bloat – and do remember whatever solution you do use that in it’s self is a dependency.

To close, I am also left with the impression that many developers want to or would wish to implement DI as a way around the after affects of poor design thinking that they are safe from it’s [DI] use.

The use of any DI solution does not solve nor excuse issues brought upon by poor design.

class Car {

public function __construct(Engine $engine) {

You don’t need your car worrying about how to create it’s own engine.

Constructor injection is generally used when the injected dependency will last the lifetime of the object or the dependency requires injection in a certain order.
Setter injection is generally used if the injected dependency has a lifetime shorter than the object it is passed into.

And since I hope you use some kind of DI container that automatically does the wiring for you (e.g. based on some kind of configuration file), it should basically not matter how the wiring is done.

With regards to where the engine is constructed, I would make the assumption (and the practical choice) of building a Factory where the Engine is constructed and then placed into the Car along with the Car’s other components (Wheels, Brakes, Transmission, etc.). While Rob is right in that I did not show that a consumer of an Engine would not need to know how an Engine works, my example was far from feature complete and a fully feature complete example would have been nearly impossible.

I do appreciate the comments, and I merit in each approach.

http://www.potstuck.com/2009/01/08/php-dependency-injection/

class Engine
{
protected $radiator;

public function setRadiator(RadiatorI $r) {
$this->radiator = $r;
}

public function getRadiator() {
if (!$this->radiator) $this->radiator = new
DefaultRadiator();
return $this->radiator;
}
}

This variant allows use of the engine without knowing it even has a radiator; however, consumers that are savvy about such things can still inject their own radiator.

Variant 2:

class Engine
{
protected $parts;

public function __construct(Parts $p) {
$this->parts = $p;
}

… // code that needs a radiator.
$radiator = $this->parts->getRadiator();
}

// In this case, Parts can act like a broker that injects those objects that are necessary, and apps can tell the broker they want a specific radiator to be used whenever someone requests it.

(e.g. Government calls $parts->setRadiator(new EcoFriendlyRadiator());

e.g. if I have class Car that uses an Engine, the car now needs to know about Pistons etc. At the car level of abstraction, you may want to swap in different types of engine (e.g. remove a petrol one and replace with an electric one) without having to worry about the type of pistons the new engine uses.

I think it would be beneficial to provide some discussion on the practical ways to instantiate an object like this. Obviously a DI system like Pico is one way, or a factory function could also be used.

Regards,

Rob…