It is now time to define the dependency inversion principle:

Modules should depend on abstractions rather than on concrete implementations.

Abstractions represent the high-level details of a module, and the interaction among modules should be done at this level. Low-level details are volatile and ever-evolving. We previously stated that there are no problems with evolved modules, but of course, we don't want to break module interactions because of low-level details, and an excellent way to do this is to use abstractions rather than concrete implementations. The following questions will help you identify how well you are doing:

• Do I have abstractions as part of my modules?

As discussed earlier in this chapter, many concrete implementations should have an abstraction in front of them. However, when it comes to one specific implementation, this is probably not the case.

• Am I creating new instances by myself every time?

The answer here should be no. Your framework or mechanism that is in charge of the dependency injection inside your application is responsible for doing this.