为什么我要利用国际奥委会的团结

本文关键字：奥委会 我要 为什么 | 更新日期: 2023-09-27 18:04:36

我创建了一个适用于依赖倒置原则的类，并使用了依赖注入模式，如下所示:

public interface ITypeOfPrinter
{
    string Printing();
}
public class Print
{  
    private readonly ITypeOfPrinter _typeOfPrinter;
    public Print(ITypeOfPrinter typeOfPrinter)
    {
        _typeOfPrinter = typeOfPrinter;
    }
    public string print()
    {
        return _typeOfPrinter.Printing();
    }
}
public class BlackAndWhitePrinter : ITypeOfPrinter
{
    public string Printing()
    {
        NumberOfPrints++;
        return string.Format("it is Black and white printing {0}", NumberOfPrints);
    }
    public int NumberOfPrints { get; set; }
}
public class ColorfullPrinter : ITypeOfPrinter
{
    public string Printing()
    {
        NumberOfPrints++;
        return string.Format("it is colorfull printing {0}", NumberOfPrints);
    }
    public int NumberOfPrints { get; set; }
}

因此，如果我想使用BlackAndWhitePrinter，我只需创建一个实例对象，并将其交给我的Print类，构造如下:

ITypeOfPrinter typeofprinter = new BlackAndWhitePrinter();
Print hp = new Print(typeofprinter);
hp.print();
为什么我必须在这里使用Unity或其他IoC框架?我已经做了上面我想要的: 
var unityContainer = new UnityContainer();
unityContainer.RegisterType<ITypeOfPrinter, BlackAndWhitePrinter>();
var print = unityContainer.Resolve<Print>();
string colorfullText = print.print();

为什么我要利用国际奥委会的团结

依赖注入模式有助于使应用程序代码更易于维护。DI框架(又名IoC容器)可以帮助使组合根更易于维护。

但是，如果IoC容器不能帮助您的组合根更易于维护，那么就不要在这种情况下使用它!但是，这并不意味着您不应该使用依赖注入或其他有助于提高软件可维护性的模式和原则。您应该尽一切可能降低您正在构建的软件的总拥有成本。

作为Steven回答的补充，使用IOC框架有几个令人信服的理由，这些理由并不适用于你给出的简单例子，但可以很容易地适用于更复杂的应用;但我同意，如果你觉得它没有带来好处，你实际上不必使用它。

当你的类不是由你直接创建，而是由框架创建时。

典型的例子是ASP.NET Controller/ApiController。您永远不会自己实例化这些，ASP.NET框架会为您完成这些。在这种情况下，如果你的控制器有依赖，那么IOC框架允许你很容易地通过接口在控制器上声明这些依赖，而不用担心它们是如何被提供的。

这样可以解耦你的类，同时也允许更容易的单元测试，因为你可以模拟/存根依赖。

当你有复杂的对象图需要构造时。下面是我正在做的一个项目的匿名但真实的图表:

 new DeathStar(new NotAMoon(),
               new PlanetExploder(),
                new ExhaustPort(new CriticalVulnerabilityIgnorer()),
                new StormTrooperGenerator(new DodgyBlasterGenerator(),
                    new HeadDoorBumper(new Ouch()),
                    new ShieldGenerator(new FurryCreatureVulnerability)),
                    new DramaticDuel(new Saber()), new DeadJedi()),
                new DroidFactory(),
                new TrashCompactor(new Monster()),
                new Emperor(new Vader())
            );

我不知道你是怎么想的，但当我需要一个新的IDeathStar时，我不想输入这个(更不用说试图维护或调试它了)——我宁愿说

var moon= IOCFrameworkOfChoice.Resolve<IDeathStar>();

或者更现实的:

public class MyController: Controller
{
    public MyController(IDeathStar star)
    {
        //at runtime, at this point I have an armed and fully operational IDeathStar
        //without having to worry about where it came from!
    }
}
相关文章：