Inject Dependencies

An object has a dependency when it knows the name of another class. The more coupled two objects are, the more they behave like a single entity.

In truth, dealing with the name change is a minor issue. You likely have a tool to do a global find/replace within a project.

It is not the class of the object that’s important. It’s the message you plan to send to it.

Using dependency injection to shape code relies on your ability to recognize that the responsibility for knowing the name of a class and the responsibility for knowing the name of a message to send to that class may belong in different objects.[¹]

Classes will be decoupled if you are mindful of dependencies and develop a habit of injecting them.

An application whose classes are entangled with obscure class name references is inflexible. In contrast, one whose class name dependencies are concise, explicit, and isolated can adapt to new requirements.

—

[¹]: Sandi Metz(2013): Practical Object-Oriented Design in Ruby (https://www.amazon.com/Practical-Object-Oriented-Design-Agile-Primer/dp/0134456475)