目前我正在研究Racing-Car-Katas 。我们的目标是重构一段代码,使其遵循可靠的原则。
我尝试添加 Dependency Inversion Principle 。我可以在其中通过构造函数传递依赖项。
初始情况
Alarm
类内部是依赖项 Sensor
,它生成 psiPressureValue
。
public class Alarm {
Sensor sensor = new Sensor();
public void check()
{
double psiPressureValue = sensor.popNextPressurePsiValue();
/* ... */
}
}
想法
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();
/* ... */
}
}
如果这是一个真正的应用程序,我不想破坏 Alarm
和 Sensor
之间的任何依赖关系。我将创建以下构造函数
public Alarm() {
this.sensor = new Sensor();
}
但我的直觉告诉我这是代码味道..
如何在现实应用程序中处理此类依赖关系?
最佳答案
依赖倒置原则 (DIP) 指出:
High-level modules should not depend on low-level modules.
但是,通过定义创建 Sensor
实现的默认构造函数,您违反了 DIP,因为 Sensor
是一个低级模块和 Alarm(您的高级别模块)。 -level 模块)依赖于它:
public Alarm() {
this.sensor = new Sensor();
}
如果需要让高级模块依赖于抽象(如附加构造函数所示),则无需添加默认构造函数。这样做只会将依赖关系拖到低级模块。由于您的最终应用程序和测试都应该使用重载的构造函数,因此默认构造函数没有任何意义,只会导致紧密耦合,从而违反 DIP。
这不是一个理论练习。在实际应用中应遵循 DIP。精心设计的实际应用程序会应用 SOLID 原则,并使用依赖注入(inject)作为实现松散耦合和 DIP 的方法。这解耦了模块并允许在 Composition Root 中组成完整的对象图。 .
关于oop - 重构 - 打破依赖关系,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/52672869/