我可以称之为依赖项注入吗

本文关键字：注入 依赖 称之为 我可以 | 更新日期: 2023-09-27 18:29:57

我是依赖项注入的新手，我正在努力解决这个问题。比方说我有课书：

class Book
{
    public String Author { get; set; }
    public String Title { get; set; }
    private int Quantity {get;set;}
    public Book(String aut, String pav, int qua)
    {
        this.Author = aut;
        this.Title = pav;
        this.Quantity = qua;
    }
}

然后是类型为的其他类书籍

class BookWithType
{
    public Book Book { get; set; }
    public String Type { get; set; }
    public BookWithType(Book book, String type)
    {
        this.Book = book;
        this.Type = type;
    }
 }

当在BookWithType构造函数中注入Book对象时，我可以说这是一个依赖项注入吗？

我可以称之为依赖项注入吗

您不会使用数据传输对象创建依赖项注入。它更像是：

public class Book
{
    public String Author { get; set; }
    public String Title { get; set; }
    public int Pages {get;set;}
    public string Type {get;set;}
    public Book(String aut, String pav, int pages, string type)
    {
        this.Author = aut;
        this.Title = pav;
        this.Pages = pages;
        this.Type = type;
    }
}

然后是某种显示层，比如：

public class BookView
{
    private IBookRetriever _bookRetriever;
    public BookWithType(IBookRetriever bookRetriever)
    {
        _bookRetriever = bookRetriever;
    }
    public Book GetBookWithType(string type) {
        return _bookRetriever.GetBookOfType(type);
    }
}

哪里的IBookRetriever。。。

public interface IBookRetriever {
    Book GetBookOfType(string type);
}

依赖注入模式的目的是创建松散耦合的组件，而不依赖于其他组件。那么，直接使用具体实现有什么错呢？问题是，未来可能很难支持这样的系统。相反，当你有松散耦合的类时，很容易改变它们的行为：你只需要提供另一个抽象的实现。

Christos给出了一个很好的例子。您的BookWithType类不再依赖于具体的Book，而是依赖于IBook抽象。因此，如果需要，您可以提供IBook的不同实现。但是，您可能不会从这个例子中看到使用DI的全部功能，因为它相当简化。相反，将数百个组件连接在一起的庞大系统成像：如何对抗复杂性？答案是使用最佳编程实践，而DI就是其中的佼佼者。

最重要的是，使用松散耦合的组件，您将获得高度可测试的系统，在哪里编写单元测试是一种乐趣：您可以轻松地提供mock/stub等，而不是具体的实现。

所以，你的问题的答案是"否"。您不能将其称为依赖注入（在"DI"模式的含义范围内）。

相关文章：