如何在不破坏封装的情况下使用依赖注入？

Question

如何在不破坏封装的情况下执行依赖注入？

使用来自维基百科的依赖注入示例：

public Car {
    public float getSpeed();
}

注意：其他方法和属性（例如 PushBrake()、PushGas()、 SetWheelPosition() ) 省略 清晰度

这效果很好；你不知道我的对象如何实现 getSpeed - 它是“封装的”。

实际上，我的对象将 getSpeed 实现为：

public Car {
    private m_speed;
    public float getSpeed( return m_speed; );
}

一切都很好。有人构建了我的 Car 对象，踩下踏板、喇叭、方向盘，然后汽车做出响应。

现在假设我更改了汽车的内部实现细节：

public Car {
    private Engine m_engine;
    private float m_currentGearRatio;
    public float getSpeed( return m_engine.getRpm*m_currentGearRatio; );
}

一切都很好。 Car 遵循正确的 OO 原则，隐藏了如何完成某些事情的细节。这使得呼叫者可以自由地解决他的问题，而不是试图了解汽车的工作原理。它还让我可以自由地更改我认为合适的实现。

但是依赖注入会迫使我将我的类暴露给我没有创建或初始化的 Engine 对象。更糟糕的是，我现在暴露了我的汽车甚至有引擎：

public Car {
   public constructor(Engine engine);
   public float getSpeed();
}

现在外界知道我使用引擎 。我并不总是使用引擎，我可能不想在将来使用Engine，但我不能再改变我的内部实现：

public Car {
    private Gps m_gps;
    public float getSpeed( return m_gps.CurrentVelocity.Speed; )
}

在不破坏调用者的情况下：

public Car {
   public constructor(Gps gps);
   public float getSpeed();
}

但是依赖注入打开了一个完整的罐子蠕虫：打开整罐蠕虫。依赖注入要求公开我的所有对象私有实现细节。我的 Car 类的使用者现在必须理解并处理我的类之前隐藏的所有内部复杂性：

public Car {
   public constructor(
       Gps gps, 
       Engine engine, 
       Transmission transmission,
       Tire frontLeftTire, Tire frontRightTire, Tire rearLeftTire, Tire rearRightTire, 
       Seat driversSeat, Seat passengersSeat, Seat rearBenchSeat,
       SeatbeltPretensioner seatBeltPretensioner,
       Alternator alternator, 
       Distributor distributor,
       Chime chime,
       ECM computer,
       TireMonitoringSystem tireMonitor
       );
   public float getSpeed();
}

我如何利用依赖注入的优点来帮助单元测试，同时不破坏封装对于提高可用性有何好处？

另请参阅

• 依赖注入必须以牺牲封装为代价吗？ （必须，而不是如何）

---

为了好玩，我可以将 getSpeed 示例缩减为所需的内容：

public Car {
   public constructor(
       Engine engine, 
       Transmission transmission,
       Tire frontLeftTire, Tire frontRightTire
       TireMonitoringSystem tireMonitor,
       UnitConverter unitsConverter
       );
   public float getSpeed()
   {
      float tireRpm = m_engine.CurrentRpm * 
              m_transmission.GetGearRatio( m_transmission.CurrentGear);

      float effectiveTireRadius = 
         (
            (m_frontLeftTire.RimSize + m_frontLeftTire.TireHeight / 25.4)
            +
            (m_frontRightTire.RimSize + m_frontRightTire.TireHeight / 25.4)
         ) / 2.0;

      //account for over/under inflated tires
      effectiveTireRadius = effectiveTireRadius * 
            ((m_tireMonitor.FrontLeftInflation + m_tireMontitor.FrontRightInflation) / 2.0);

      //speed in inches/minute
      float speed = tireRpm * effetiveTireRadius * 2 * Math.pi;

      //convert to mph
      return m_UnitConverter.InchesPerMinuteToMilesPerHour(speed);
   }
}

---

更新： 也许可以遵循以下一些答案问题的线索，并给出示例代码？

public Car {
    public float getSpeed();
}

---

另一个例子是当我的类依赖于另一个对象时：

public Car {
    private float m_speed;
}

在这种情况下，float 是一个用于表示浮点值的类。根据我的阅读，每个依赖类都应该被注入 - 以防我想模拟 float 类。这引发了必须注入每个私有成员的担忧，因为一切从根本上来说都是一个对象：

public Car {
    public Constructor(
        float speed,
        float weight,
        float wheelBase,
        float width,
        float length,
        float height,
        float headRoom,
        float legRoom,
        DateTime manufactureDate,
        DateTime designDate,
        DateTime carStarted,
        DateTime runningTime,
        Gps gps, 
        Engine engine, 
        Transmission transmission,
        Tire frontLeftTire, Tire frontRightTire, Tire rearLeftTire, Tire rearRightTire, 
        Seat driversSeat, Seat passengersSeat, Seat rearBenchSeat,
        SeatbeltPretensioner seatBeltPretensioner,
        Alternator alternator, 
        Distributor distributor,
        Chime chime,
        ECM computer,
        TireMonitoringSystem tireMonitor,
        ...
     }

这些确实是我不希望客户必须查看的实现细节。

Answer 1

许多其他答案都暗示了这一点，但我要更明确地说，是的，依赖注入的幼稚实现可以破坏封装。

避免这种情况的关键是调用代码不应直接实例化依赖项（如果它不关心它们）。这可以通过多种方式完成。

最简单的是有一个默认构造函数来使用默认值进行注入。只要调用代码仅使用默认构造函数，您就可以在幕后更改依赖项，而不会影响调用代码。

如果您的依赖项本身具有依赖项等，那么这可能会开始失控。那时工厂模式就可以到位（或者您可以从一开始就使用它，以便调用代码已经在使用工厂）。如果您引入工厂并且不想破坏代码的现有用户，则始终可以从默认构造函数调用工厂。

除此之外，还有控制反转的使用。我对 IoC 的使用还不够多，无法对其进行太多讨论，但这里有很多关于它的问题，而且网上的文章比我能更好地解释它。

如果它应该真正封装到调用代码无法知道依赖项的地方，那么可以选择进行注入（带有依赖项参数的构造函数或设置器）内部 如果语言支持它，或者将它们设为私有，并让您的单元测试使用诸如反射之类的东西（如果您的语言支持它）。如果你的语言都不支持，那么我想可能有一个类，调用代码正在实例化一个虚拟类，该类只是封装了真正工作的类（我相信这是外观模式，但我从来没有正确记住这些名称） ）：

public Car {
   private RealCar _car;
   public constructor(){ _car = new RealCar(new Engine) };
   public float getSpeed() { return _car.getSpeed(); }
}

Answer 2

如果我正确理解您的担忧，那么您正在尝试阻止任何需要实例化新 Car 对象的类必须手动注入所有这些依赖项。

我使用了几种模式来做到这一点。在具有构造函数链接的语言中，我指定了一个默认构造函数，它将具体类型注入另一个依赖注入的构造函数中。我认为这是一种非常标准的手动 DI 技术。

我使用的另一种方法（允许更松散的耦合）是创建一个工厂对象，该对象将使用适当的依赖项配置 DI 对象。然后我将这个工厂注入到任何需要在运行时“新”一些汽车的对象中；这也允许您在测试期间注入完全伪造的 Car 实现。

并且总是有 setter 注入方法。该对象的属性将具有合理的默认值，可以根据需要用测试替身替换。不过，我确实更喜欢构造函数注入。

---

编辑以显示代码示例：

interface ICar { float getSpeed(); }
interface ICarFactory { ICar CreateCar(); }

class Car : ICar { 
  private Engine _engine;
  private float _currentGearRatio;

  public constructor(Engine engine, float gearRatio){
    _engine = engine;
    _currentGearRatio = gearRatio;
  }
  public float getSpeed() { return return _engine.getRpm*_currentGearRatio; }
}

class CarFactory : ICarFactory {
  public ICar CreateCar() { ...inject real dependencies... }    
}

然后消费者类只需通过接口与其交互，完全隐藏任何构造函数。

class CarUser {
  private ICarFactory _factory;

  public constructor(ICarFactory factory) { ... }

  void do_something_with_speed(){
   ICar car = _factory.CreateCar();

   float speed = car.getSpeed();

   //...do something else...
  }
}

Answer 3

我认为您正在破坏 Car 构造函数的封装。具体来说，您规定必须将 Engine 注入到 Car 中，而不是使用某种类型的接口来确定您的速度（IVelocity 中的如下例。）

通过接口，Car 能够获取其当前速度，而与决定该速度的因素无关。例如：

public Interface IVelocity {
   public float getSpeed();
}

public class Car {
   private m_velocityObject;
   public constructor(IVelocity velocityObject) { 
       m_velocityObject = velocityObject; 
   }
   public float getSpeed() { return m_velocityObject.getSpeed(); }
}

public class Engine : IVelocity {
   private float m_rpm;
   private float m_currentGearRatio;
   public float getSpeed( return m_rpm * m_currentGearRatio; );
}

public class GPS : IVelocity {
    private float m_foo;
    private float m_bar;
    public float getSpeed( return m_foo * m_bar; ); 
}

引擎或 GPS 可以根据其工作类型拥有多个接口。接口是 DI 的关键，没有它 DI 就会破坏封装。

Answer 4

这是我认为您必须使用依赖注入容器的地方，它可以让您封装汽车的创建，而不让您的客户端调用者需要知道如何创建它。下面是 symfony 解决这个问题的方法（尽管不是同一种语言，但原理是一样的）：

http://components.symfony-project.org/dependency-injection/documentation

有一个关于依赖注入容器的部分。

简而言之，总结一下直接从文档页面引用的内容：

使用容器时，我们只需要询问
对于邮件程序对象[这将是您示例中的汽车]，我们不需要
了解有关如何创建的任何信息
不再这样了；关于的所有知识
如何创建一个实例
mailer [car] 现已嵌入到
容器。

希望对您有帮助

Answer 5

工厂和接口。

您有几个问题。

1. 如何实现相同操作的多个实现？
2. 如何向对象的使用者隐藏对象的构造细节？

因此，您需要的是将真正的代码隐藏在 ICar 接口后面，如果需要的话创建一​​个单独的 EnginelessCar，并使用 ICarFactory > 接口和一个 CarFactory 类，用于向汽车消费者隐藏构造细节。

这可能最终看起来很像依赖注入框架，但您不必使用它。

根据我在另一个问题中的回答，这是否会破坏封装完全取决于您如何定义封装。我见过两种常见的封装定义：

1. 逻辑实体上的所有操作都作为类成员公开，并且该类的使用者不需要使用其他任何东西。
2. 类具有单一职责，并且管理该职责的代码包含在该类中。也就是说，在对类进行编码时，您可以有效地将其与其环境隔离，并缩小您正在使用的代码的范围。

（像第一个定义这样的代码可以存在于适用于第二个条件的代码库中 - 它往往仅限于外观，并且这些外观往往具有最少的逻辑或没有逻辑）。

Answer 6

我已经很久没有使用Delphi了。 DI 在 Spring 中的工作方式，您的 setter 和构造函数不是接口的一部分。因此，您可以拥有一个接口的多个实现，一个可能使用基于构造函数的注入，另一个可能使用基于设置器的注入，使用该接口的代码并不关心。注入的内容位于应用程序上下文 xml 中，这是唯一暴露依赖项的地方。

编辑：
无论您是否使用框架，您都在做同样的事情，您都有一个将对象连接在一起的工厂。因此，您的对象在构造函数或设置器中公开这些详细信息，但您的应用程序代码（在工厂之外，不包括测试）从不使用它们。无论哪种方式，您都选择从工厂获取对象图，而不是即时实例化内容，并且您选择不执行诸如在要注入的代码中使用设置器之类的操作。这是我从某些人的代码中看到的“钉住一切”哲学的思维转变。

Answer 7

我不认为汽车是依赖注入在现实世界中的实用性的一个特别好的例子。

我认为在您的最后一个代码示例中，Car 类的目的尚不清楚。是一个保存数据/状态的类吗？它是计算速度之类的服务吗？或者它是一个混合体，允许您构建其状态，然后调用其上的服务以基于该状态进行计算？

在我看来，Car 类本身可能是一个有状态对象，其目的是保存其组成的详细信息，并且计算速度的服务（如果需要，可以注入）将是一个单独的类（具有类似“getSpeed(ICar car)”的方法）。许多使用 DI 的开发人员倾向于将有状态对象和服务对象分开——尽管在某些情况下一个对象同时具有状态和服务，但大多数倾向于分开。此外，绝大多数 DI 使用往往是在服务端。

下一个问题是：汽车类别应该如何组成？意图是每辆特定汽车只是 Car 类的一个实例，还是为从 CarBase 或 ICar 继承的每个品牌和型号都有一个单独的类？如果是前者，那么一定有一些方法可以将这些值设置/注入到汽车中——即使您从未听说过依赖倒置，也没有办法解决这个问题。如果是后者，那么这些值只是汽车的一部分，我认为没有理由让它们可设置/可注入。这取决于诸如引擎和轮胎之类的东西是否特定于实现（硬依赖项）或者它们是否是可组合的（松散耦合依赖项）。

我知道汽车只是一个例子，但在现实世界中，您将成为知道反转对类的依赖关系是否违反封装的人。如果确实如此，您应该问的问题是“为什么？”而不是“如何？” （当然，这就是你正在做的事情）。

Answer 8

您应该将代码分为两个阶段：

1. 通过工厂或 DI 解决方案构建特定生命周期的对象图
2. 运行这些对象（这将涉及输入和输出）

在汽车工厂，他们需要知道如何制造汽车。他们知道它有什么样的发动机，喇叭是如何接线的等等。这是上面的第一阶段。汽车厂可以制造不同的汽车。

当你驾驶汽车时，你可以驾驶任何符合你期望的汽车接口的东西。例如踏板、方向盘、喇叭。当您开车时，踩刹车时您不知道内部细节。但是，您可以看到结果（速度变化）。

封装得以保留，因为驾驶汽车的人不需要知道它是如何制造的。因此，您可以使用同一个驱动程序来驾驶许多不同的汽车。当司机需要一辆车时，应该给他们一辆。如果他们在意识到需要时构建自己的封装，那么封装就会被破坏。

Answer 9

现在，对于完全不同的东西......

您想要依赖注入的优点而不破坏封装。依赖注入框架可以为您做到这一点，但是通过创造性地使用虚拟构造函数、元类注册和在项目中选择性包含单元，您还可以使用“穷人的依赖注入”。

但它确实有一个严重的限制：每个项目中只能有一个特定的引擎类。没有选择引擎的选择，但仔细想想，您可能会弄乱元类变量的值来实现这一点。但我有点超前了。

另一个限制是单行继承：只有主干，没有分支。至少对于单个项目中包含的单元而言是这样。

您似乎正在使用 Delphi，因此下面的方法将起作用，因为它是我们自 D5 以来一直在需要类 TBaseX 的单个实例的项目中使用的方法，但不同的项目需要该基类的不同后代，我们希望能够通过简单地删除一个单元并添加另一个单元来交换课程。不过，该解决方案并不局限于 Delphi。它将与任何支持虚拟构造函数和元类的语言一起使用。

那么你需要什么？

好吧，您希望能够根据每个项目包含的单元进行交换的每个类都需要有一个变量，您可以在其中存储要实例化的类类型：

var
  _EngineClass: TClass;

每个实现 Engine 的类都应该使用以下方法在 _EngineClass 变量中注册自己：一种防止祖先取代后代的方法（这样您就可以避免对单元初始化顺序的依赖）：

procedure RegisterMetaClass(var aMetaClassVar: TClass; const aMetaClassToRegister: TClass);
begin
  if Assigned(aMetaClassVar) and aMetaClassVar.InheritsFrom(aMetaClassToRegister) then
    Exit;

  aMetaClassVar := aMetaClassToRegister;
end;

可以在公共基类中完成类的注册：

  TBaseEngine
  protected
    class procedure RegisterClass; 

class procedure TBaseEngine.RegisterClass;
begin
  RegisterMetaClass(_EngineClass, Self);
end;

每个后代通过在其单元的初始化中调用注册方法来注册自己部分：

type
  TConcreteEngine = class(TBaseEngine)
  ...
  end;

initialization
  TConcreteEngine.RegisterClass;

现在您所需要的只是实例化“最后代”注册类，而不是硬编码的特定类。

  TBaseEngine
  public
    class function CreateRegisteredClass: TBaseEngine; 

class function TBaseEngine.CreateRegisteredClass: TBaseEngine;
begin
  Result := _EngineClass.Create;
end;

当然，您现在应该始终使用此类函数来实例化引擎，而不是普通的构造函数。

如果您这样做，您的代码现在将始终实例化项目中存在的“最后代”引擎类。您可以通过包含或不包含特定单元来在课程之间进行切换。例如，您可以通过使模拟类成为实际类的祖先并且不在测试项目中包含实际类来确保您的测试项目使用模拟类；或者使模拟类成为实际类的后代，并且不在正常代码中包含模拟；或者 - 甚至更简单 - 通过在项目中包含或者模拟或实际类。

---

在此实现示例中，模拟类和实际类具有无参数构造函数。情况不一定如此，但由于 var 参数，您将需要使用特定的元类（而不是 TClass）并在对 RegisterMetaClass 过程的调用中进行一些转换。

type
  TBaseEngine = class; // forward
  TEngineClass = class of TBaseEngine;
var
  _EngineClass: TEngineClass

type
  TBaseEngine = class
  protected
    class procedure RegisterClass;
  public
    class function CreateRegisteredClass(...): TBaseEngine;
    constructor Create(...); virtual;

  TConcreteEngine = class(TBaseEngine)
    ...
  end;

  TMockEngine = class(TBaseEngine)
    ...
  end;

class procedure TBaseEngine.RegisterClass;
begin
  RegisterMetaClass({var}TClass(_EngineClass), Self);
end;

class function TBaseEngine.CreateRegisteredClass(...): TBaseEngine;
begin
  Result := _EngineClass.Create(...);
end;

constructor TBaseEngine.Create(...);
begin
  // use parameters in creating an instance.
end;

玩得开心！