使用IoC将依赖项注入基类和子类？

Question

如果我有一个基类通过构造函数依赖注入服务:是否可以在不使用的情况下声明子类的构造函数: base (params)？

public MyBaseClass
{
   private IServiceA _serviceA;
   private IServiceB _serviceB;
   private IServiceC _serviceC;

   public MyBaseClass(null, null, null)
   public MyBaseClass(IServiceA serviceA, IServiceB serviceB, IServiceC serviceC)
   {
       _serviceA = serviceA;
       _serviceB = serviceB;
       _serviceC = serviceC;
   }
}

并且注入了一些额外依赖项的子类:

public MySubClassA : MyBaseClass
{
   private IServiceD _serviceD;

   public MySubClassA (null, null, null, null)
   public MySubClassA (IServiceA serviceA, IServiceB serviceB, 
                       IServiceC serviceC, IServiceD serviceD)
          : base (serviceA, serviceB, serviceC)
   {
       _serviceD = serviceD;
   }
}

这里的问题是我有多个子类,现在只有10个左右,但数量会增加.每次我需要向基类添加另一个依赖项时,我必须遍历每个子类并在那里手动添加依赖项.这个手工工作让我觉得我的设计有问题.

那么是否可以MyBaseClassA在子类的构造函数中声明构造函数而不需要基类所需的服务？例如,以便构造函数 MyBaseClassA只有这么简单的代码:

   public MySubClassA (null)
   public MySubClassA (IServiceD serviceD)
   {
       _serviceD = serviceD;
   }

我需要在基类中进行哪些更改,以便在那里进行依赖注入,也不需要将其添加到子类中？我正在使用LightInject IoC.

Answer 1

这个手工工作让我觉得我的设计有问题.

可能有.您提供的示例很难具体说明,但这种问题通常是由以下原因之一引起的:

• 您可以使用基类来实现横切关注点(例如日志记录,事务处理,安全检查,验证等),而不是装饰器.
• 您可以使用基类来实现共享行为,而不是将该行为放在可以注入的单独组件中.

基类通常被滥用于向实现添加横切关注点.在这种情况下,基类很快就会变成一个上帝对象:一个做得太多而且知道得太多的类.它违反了单一责任原则(SRP),导致它经常变化,变得复杂,并且难以测试.

该问题的解决方案是一起删除基类,并使用多个装饰器而不是单个基类.你应该为每个跨领域的问题写一个装饰者.这样每个装饰器都很小而且专注,只有一个改变的理由(单一责任).通过使用基于通用接口的设计,您可以创建通用装饰器,它可以包装一组与架构相关的类型.例如,一个装饰器可以包装系统中的所有用例实现,或者一个装饰器包装系统中具有特定返回类型的所有查询.

基类通常是滥用以包含一组不相关的功能,这些功能可由多个实现重用.不是将所有这些逻辑放在基类中(使基类成长为维护噩梦),而是应将此功能提取到实现可依赖的多个服务中.

当你开始重构这样的设计时,你会经常看到实现开始获得许多依赖,一种称为构造函数过度注入的反模式.构造函数过度注入通常表明类违反了SRP(使其复杂且难以测试).但是将逻辑从基类移动到依赖项并没有使实现更难以测试,事实上,具有基类的模型具有相同的问题,但不同之处在于依赖性被隐藏起来.

仔细查看实现中的代码时,您经常会看到某种重复的代码模式.多个实现以相同的方式使用相同的依赖集.这是一个缺少抽象的信号.此代码及其依赖项可以提取到聚合服务中.聚合服务减少了实现所需的依赖项数量,并包含了常见行为.

使用Aggregate服务看起来像@SimonWhitehead在评论中讨论的'包装器',但请注意聚合服务是关于抽象依赖性和行为.如果您创建依赖项的"容器"并通过公共属性公开这些依赖项以供实现使用它们,那么您不会降低实现所依赖的依赖项数量,并且您不会降低此类的复杂性并且您不会该实现更容易测试.另一方面,聚合服务确实降低了依赖项的数量和类的复杂性,使其更易于掌握和测试.

遵循这些规则时,在大多数情况下不需要具有基类.