IoC 和构造函数过度注入反模式解析

Question

这个问题是 Jeffery Palermo 关于如何绕过分支代码和依赖注入的帖子的结果 http://jeffreypalermo.com/blog/constructor-over-injection-anti-pattern/

在他的帖子中，Jeffery 有一个类（public class OrderProcessor ： IOrderProcessor），在构造函数上采用 2 个接口。一种是验证器 IOrderValidator 和 IOrderShipper 接口。他的方法代码仅在使用 IOrderValidator 接口上的方法后分支，并且从未使用 IOrderShipper 接口上的任何内容。

他建议创建一个工厂来调用静态方法来获取接口的委托。他正在重构的代码中创建一个新对象，这似乎没有必要。

我想问题的关键是我们正在使用 IoC 来构建所有对象，无论它们是否被使用。 如果您实例化一个具有 2 个接口的对象，并且具有可以分支而不使用其中一个接口的代码，您如何处理它？<​​/strong>

在此示例中，我们假设 _validator.Validate( order) 始终返回 false，并且永远不会调用 IOrderShipper.Ship() 方法。

原始代码：

public class OrderProcessor : IOrderProcessor
{
    private readonly IOrderValidator _validator;
    private readonly IOrderShipper _shipper;

    public OrderProcessor(IOrderValidator validator, IOrderShipper shipper)
    {
      _validator = validator;
      _shipper = shipper;
    }

    public SuccessResult Process(Order order)
    {
      bool isValid = _validator.Validate(order);
      if (isValid)
      {
          _shipper.Ship(order);
      }
      return CreateStatus(isValid);
    }

    private SuccessResult CreateStatus(bool isValid)
    {
        return isValid ? SuccessResult.Success : SuccessResult.Failed;
    }
}

public class OrderShipper : IOrderShipper
{
  public OrderShipper()
  {
      Thread.Sleep(TimeSpan.FromMilliseconds(777));
  }

  public void Ship(Order order)
  {
      //ship the order
  }
}

重构代码

public class OrderProcessor : IOrderProcessor
{
    private readonly IOrderValidator _validator;

    public OrderProcessor(IOrderValidator validator)
    {
      _validator = validator;
    }

    public SuccessResult Process(Order order)
    {
      bool isValid = _validator.Validate(order);
      if (isValid)
      {
          IOrderShipper shipper = new OrderShipperFactory().GetDefault();
          shipper.Ship(order);
      }
      return CreateStatus(isValid);
    }

    private SuccessResult CreateStatus(bool isValid)
    {
        return isValid ? SuccessResult.Success : SuccessResult.Failed;
    }
}   

public class OrderShipperFactory
{
    public static Func<IOrderShipper> CreationClosure;
    public IOrderShipper GetDefault()
    {
        return CreationClosure(); //executes closure
    }
}

下面是在启动时配置此工厂的方法时间（ASP.NET 的 global.asax）：

private static void ConfigureFactories()
{
    OrderShipperFactory.CreationClosure =
        () => ObjectFactory.GetInstance<IOrderShipper>();
}

Answer 1

我刚刚发布了对 Jeffrey Palermos 帖子的反驳。

总之，我们不应该让具体的实现细节影响我们的设计。这将违反建筑规模上的里氏替换原则。

一个更优雅的解决方案让我们通过引入延迟加载 OrderShipper 来保留设计。

Answer 2

我开会迟到了，但有几点要点...

坚持仅使用一个依赖项的代码分支，有两个分支可供建议：

• 应用 DDD 实践，您将不会拥有依赖于 IOrderValidator 的 OrderProcessor 。相反，您可以让 Order() 实体负责其自身的验证。或者，坚持使用 IOrderValidator，但在已实现的 OrderShipper() 中依赖它 - 因为它将返回任何错误代码。
• 确保注入的依赖项是使用单例方法构建的（并在所使用的 IoC 容器中配置为单例）。这解决了任何内存问题。

就像这里提到的其他人一样，重点是打破对具体类的依赖，并使用依赖注入将依赖项与正在使用的某些 IoC 容器松散耦合。

通过限制未来产生的技术债务，使得未来的大规模重构和替换遗留代码变得更加容易。一旦您拥有一个包含近 500,000 行代码和 3000 个单元测试的项目，您就会直接了解为什么 IoC 如此重要。