你在使用什么依赖注入框架?你尝试过使用基于setter的注入吗?

基于构造函数的注入的好处是，对于不使用依赖注入框架的Java程序员来说，它看起来很自然。你需要5个东西来初始化一个类，然后你的构造函数有5个参数。缺点正如你所注意到的，当你有很多依赖时，它会变得笨拙。

在Spring中，你可以使用setter来传递所需的值，并且可以使用@required注释来强制注入这些值。缺点是您需要将初始化代码从构造函数移动到另一个方法，并在所有依赖项注入后通过使用@PostConstruct进行标记让Spring调用该方法。我不确定其他框架，但我认为它们做了类似的事情。

两种方法都有效，这是一个偏好的问题。

传入参数的困难不是问题。问题是你的类做的太多了，应该再分解一些。

依赖注入可以作为类变得太大的早期警告，特别是因为传递所有依赖的痛苦正在增加。

你在使用什么依赖注入框架?你尝试过使用基于setter的注入吗?

基于构造函数的注入的好处是，对于不使用依赖注入框架的Java程序员来说，它看起来很自然。你需要5个东西来初始化一个类，然后你的构造函数有5个参数。缺点正如你所注意到的，当你有很多依赖时，它会变得笨拙。

在Spring中，你可以使用setter来传递所需的值，并且可以使用@required注释来强制注入这些值。缺点是您需要将初始化代码从构造函数移动到另一个方法，并在所有依赖项注入后通过使用@PostConstruct进行标记让Spring调用该方法。我不确定其他框架，但我认为它们做了类似的事情。

两种方法都有效，这是一个偏好的问题。

这就是我使用的方法

public class Hero
{

    [Inject]
    private IInventory Inventory { get; set; }

    [Inject]
    private IArmour Armour { get; set; }

    [Inject]
    protected IWeapon Weapon { get; set; }

    [Inject]
    private IAction Jump { get; set; }

    [Inject]
    private IInstanceProvider InstanceProvider { get; set; }


}

下面是如何执行注入和在注入值后运行构造函数的粗略方法。这是一个功能齐全的程序。

public class InjectAttribute : Attribute
{

}


public class TestClass
{
    [Inject]
    private SomeDependency sd { get; set; }

    public TestClass()
    {
        Console.WriteLine("ctor");
        Console.WriteLine(sd);
    }
}

public class SomeDependency
{

}


class Program
{
    static void Main(string[] args)
    {
        object tc = FormatterServices.GetUninitializedObject(typeof(TestClass));

        // Get all properties with inject tag
        List<PropertyInfo> pi = typeof(TestClass)
            .GetProperties(BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.Public)
            .Where(info => info.GetCustomAttributes(typeof(InjectAttribute), false).Length > 0).ToList();

        // We now happen to know there's only one dependency so we take a shortcut just for the sake of this example and just set value to it without inspecting it
        pi[0].SetValue(tc, new SomeDependency(), null);


        // Find the right constructor and Invoke it. 
        ConstructorInfo ci = typeof(TestClass).GetConstructors()[0];
        ci.Invoke(tc, null);

    }
}

我目前正在做一个类似这样的爱好项目 https://github.com/Jokine/ToolProject/tree/Core

我不认为你的类构造函数应该引用你的IOC容器期。这代表了类和容器之间不必要的依赖关系(IOC试图避免的依赖类型!)

你是对的，如果你使用容器作为一个服务定位器，它或多或少是一个美化的静态工厂。出于很多原因，我认为这是一种反模式(请参阅我书中的节选)。

构造函数注入的一个好处是，它使违反单一责任原则的行为变得非常明显。

当这种情况发生时，是时候重构到Facade Services了。简而言之，创建一个新的、更粗粒度的接口，隐藏当前所需的一些或所有细粒度依赖项之间的交互。