我的类有以下构造函数
public MyClass(File f1, File f2, File f3, Class1 c1, Class2 c2, Class3 c3)
{
..........
}
可以看出,它有6个参数。看到这段代码,我的一位前辈说,与其传递 6 个参数,不如传递一个配置对象。
我以这种方式编写代码是因为最近我读到了“依赖注入”,它说“类必须要求他们想要什么”。所以我认为传递配置对象会违反原则。
我对“依赖注入”的解释正确吗?或者 我应该听从前辈的建议吗?
我的类有以下构造函数
public MyClass(File f1, File f2, File f3, Class1 c1, Class2 c2, Class3 c3)
{
..........
}
可以看出,它有6个参数。看到这段代码,我的一位前辈说,与其传递 6 个参数,不如传递一个配置对象。
我以这种方式编写代码是因为最近我读到了“依赖注入”,它说“类必须要求他们想要什么”。所以我认为传递配置对象会违反原则。
我对“依赖注入”的解释正确吗?或者 我应该听从前辈的建议吗?
在这种情况下,“配置对象”是一个迟钝的术语;它以纯机械的方式构建了您的努力。目标是将您的意图传达给课程的消费者;让我们朝着那个方向重构。
具有大量参数的方法或构造函数表明它们之间的关系松散。消费者通常需要做出更多的推论才能理解 API。这3 个文件和这 3 个类有什么特别之处?那就是没有传达的信息。
这是一个通过从隐含概念中提取显式概念来创建更有意义和意图揭示界面的机会。例如,如果这 3 个文件因用户而相关,则UserFileSet
参数将清楚地表达这一点。也许f1
与c1
、f2
toc2
和f3
to相关c3
。将这些关联声明为独立类将使参数计数减半并增加可以从 API 派生的信息量。
最终,重构将高度依赖于您的问题域。不要假设您应该创建单个对象来满足参数列表;尝试沿着参数之间关系的轮廓重构。这将始终产生比用于解决它的语言更多地反映它解决的问题的代码。
我不认为使用配置对象与使用依赖注入模式相矛盾。它更多的是关于注入依赖项的形式,以及一个一般性问题,即最好有一个接受 20 个参数的函数(在本例中为构造函数)还是将这些参数组合到一个类中以便将它们捆绑在一起。
您仍然可以自由使用依赖注入,即通过某个工厂或容器构造配置对象,并在创建类的实例时将其注入构造函数。这是否是一个好主意也取决于具体情况,没有灵丹妙药;)