使用抽象类进行依赖注入

本文关键字：依赖 注入 抽象类 | 更新日期: 2023-09-27 18:33:06

我最近两天都在努力掌握DI。

我有两个问题：

  1. 如果我有一些通用功能，为什么我不能用抽象类实现 DI 做同样的事情？

  2. 在我的示例中，我在 writefile 下创建了许多类实例，那么我应该从那里移出所有对象创建吗？如果我有分层设计怎么办？这些类应该一直传递吗？

    public interface IWriteFile
{
    void write();
}
public class WriteXMLFile : IWriteFile
{    
    public void write()
    {
    }
}
public class writefile
{
    IWriteFile _file;
    public writefile(IWriteFile file)
    {
        _file = file;
    }
    public void WriteMyFile()
    {
        _file.write();
    }
}

使用抽象类进行依赖注入

关于你的第一点：

假设你想测试使用你的抽象类的东西。如果您直接使用抽象类，那么如果您想在公共类的共享功能中做一些不同的事情，那么您无能为力。

使用接口，您已经打破了与依赖项的耦合。这就是 SOLID 中的依赖反转原则所讨论的，当它说"高级模块不应该依赖于低级模块。两者都应依赖于抽象"。您的类不应依赖较低级别的类(即使它是一个抽象类(来完成其工作。较低级别的类和高级类都应依赖于定义它们如何交互的接口。使用接口有助于将两者分开，从而提供松散耦合。其他东西可以将它们连接在一起。

关于你的第二点：

强大的 DI 框架实际上为您处理了很多这种复杂性。

假设您有一个类 - Thing - 具有一堆依赖项。

public Thing(
    IThingRepository repository, 
    IEmailer emailer, 
    ILogger logger, 
    INeedMoreStuff stuff
) : IThing

设置 IoC 容器时，需要执行以下操作来关联要用于每个接口的实现：

IoC.Register<MySqlThingRepository>().As<IThingRepository>();
IoC.Register<MicrosoftExchangeEmailer>().As<IEmailer>();
IoC.Register<TruncatingFileLogger>().As<ILogger>();
IoC.Register<MoreStuff>().As<INeedMoreStuff>();
IoC.Register<Thing>().As<IThing>();

然后你可以简单地做：

IThing thing = IoC.Resolve<IThing>();

这些花哨的框架可以为您处理获取所有依赖项(因为您告诉它如何获取它们(，并将为您构建一个Thing。

话虽如此，有时像这样的花哨框架是矫枉过正的。在这些情况下，我通常使用工厂模式来抽象出创建对象的细节，同时仍然确保正在创建的对象遵循良好的 DI 原则，例如构造函数注入其依赖项。

关于您的多态性和接口：

有人将多态性简单地描述为"相同的接口，不同的实现。可替代性"。维基百科将其定义为"为不同类型的实体提供单一界面"。根据这些定义，我认为使用接口并不违背多态性。我觉得在 C# 接口中通常足以提供同一"接口"的不同实现。

是的，您可以使用抽象基类来做同样的事情，但是只有当有一组通用功能可以分解到基类中以保持代码干燥时，我才会使用它。

关于一个接口与结构图的多个实现

我不知道 StructureMap 如何处理这个问题，但大概有一些逻辑可以决定你什么时候要使用 Thing1 而不是Things2。您也许能够向 StructureMap 提供一个委托，它可以用来获取包含该逻辑的IThing。

或者，您可以有一个工厂，该工厂采用一些参数并决定返回哪个IThing。在某些情况下，我已经在我的工厂上放置了一个接口并注入了构造函数，或者让工厂使用IThing使用该ThingFactory来创建对象来获取正确的对象。

相关文章：