Refactoring - Breaking Dependencies - oop

Question

Currently I am working on the Racing-Car-Katas. The goal is to refactor a peach of code so that it follows the solid-principles.
I try to add the Dependency Inversion Principle. Where I can pass a dependency through the constructor.
Initial Situation
Insid the class Alarm is the dependency Sensor which generates a psiPressureValue.
public class Alarm {
Sensor sensor = new Sensor();
public void check()
{
double psiPressureValue = sensor.popNextPressurePsiValue();
/* ... */
}
}
Idea
public class Alarm {
Sensor sensor;
public Alarm() {
this.sensor = new Sensor();
}
public Alarm(ISensor sensor) {
this.sensor = sensor;
}
public void check()
{
double psiPressureValue = sensor.popNextPressurePsiValue();
/* ... */
}
}
If this would be a real application I don't want to break any dependency between Alarm and Sensor. There for I would created the following constructor
public Alarm() {
this.sensor = new Sensor();
}
But my gut feeling says this is code smell..
How to handle such dependencies in real world applications?

Answer 1

The Dependency Inversion Principle (DIP) states:
High-level modules should not depend on low-level modules.
But by defining the default constructor that creates a Sensor implementation, however, you are violating the DIP, because Sensor is a low-level module and Alarm (your high-level module) takes a dependency on it:
public Alarm() {
this.sensor = new Sensor();
}
If there is a need to let the high level module depend on an abstraction (as your additional constructor shows), there is no need to add a default constructor. Doing so only drags along the dependency to the low-level module. Since both your final application and your tests should make use of the overloaded constructor, the default constructor has no meaning and only causes tight coupling and therefore a violation of the DIP.
This is not a theoretical exercise. The DIP should be followed in real-world applications. A well-designed real-world application applies the SOLID principles and uses Dependency Injection as way to achieve loose coupling and the DIP. This decouples modules and allows complete object graphs to be composed in the Composition Root.

Answer 2

In order to not break any dependency between Alarm and Sensor, you need to:
Take all the methods of Sensor that are used by Alarm;
Put them in one (or more) interface(s); and then,
Have Sensor implement those interfaces.
The second constructor approach is not the right way to secure the dependencies. It is violating the DIP by creating an object of Sensor class.
Instead of that, add validation code to the other constructor and make sure that Alarm is always using a valid Sensor through an ISensor (and not create an instance of a Sensor directly).

Answer 3

Ok you want to break the direct coupling between Alarm and Sensor.
Your proposed solutions shows two constructors, one injecting the Sensor object (created externally) and one creating Sensor object directly. You should drop:
public Alarm() {
this.sensor = new Sensor();
}
because its not needed and because it prolongs the tight coupling you are trying to avoid with SOLID. Dependency is not broken by doing this.
Broadly the most common options for creating dependencies are as below.
Dependent objects are created:
1) Directly by the Client object (tight coupling)
2) Indirectly by the Client using Factory Methods of Client
3) Indirectly by the Client using Abstract Factory object injected into the Client (the factory injection is DI). You can inject different factories.
4) Externally manually and injected into the Client (DI)
5) Externally via a DI Container and injected into the Client (DI)
Its a key point of DI that the Client does not control how its dependants are created. This is explains the term "Inversion of Control".
However, the client retains control with "Factory Method", "Abstract Factory".
DI containers have become extremely popular in recent years especially with modern frameworks.