Comparison
Dependency injectionvsHard-coded dependency
Dependency injection
the class asks for what it needs in its constructor and never goes looking, so a test can hand it anything.
Supplying a component's collaborators from outside instead of letting it construct or locate them. It is not a framework — passing an argument is dependency injection — and the whole benefit is that the dependency becomes visible in the signature and replaceable at the call site. It is the mechanical half of dependency inversion, which is the design principle about which direction the abstraction points.
Full entry →Hard-coded dependency
the class constructs its own collaborator inside a method, so testing it means standing up the real thing.
A class that names and constructs a concrete collaborator itself, welding the two together at compile time. It is the thing dependency injection is contrasted against, and the practical symptom is always the same: a unit test that needs a database, a clock or the network. Not every `new` is a problem — constructing a value object or a data structure is fine; constructing something with behaviour, I/O or a lifetime is the case to watch.
Full entry →