依赖注入与许多小类
我在Guice中有一个类在构造函数中使用依赖注入获取〜10个参数。依赖注入与许多小类
该类有许多派生类。 所有派生类的构造函数只是将所有参数传递给super。
将新参数添加到基类的构造函数中需要将此参数添加到所有派生类的所有构造函数中。
class MyBaseClass {
@Inject
MyBaseClass(arg1,arg2,arg3, ..., argn) {
this.arg1 = arg1
....
}
}
class MyDerivedClass1 extends MyBaseClass{
@Inject
MyDerivedClass1(arg1,arg2,arg3, ..., argn) {
super(arg1,arg2,arg3, ..., argn)
}
}
class MyDerivedClass2 extends MyBaseClass{
@Inject
MyDerivedClass2(arg1,arg2,arg3, ..., argn) {
super(arg1,arg2,arg3, ..., argn)
}
}
一种解决方案我不得不是包装的所有参数在一个类和注入该类基类和所有派生类。通过这种方式向该注入类添加新参数时,它将注入到所有派生类中。
喜欢的东西:
class MyBaseClassSettings {
@Inject
MyBaseClassSettings(arg1,arg2,arg3, ..., argn) {
this.arg1 = arg1
...
}
}
class MyBaseClass {
@Inject
MyBaseClass(MyBaseClassSettings settings) {
this.settings = settings;
}
}
class MyDerivedClass1 extends MyBaseClass{
@Inject
MyDerivedClass1(MyBaseClassSettings settings) {
super(settings)
}
}
class MyDerivedClass2 extends MyBaseClass{
@Inject
MyDerivedClass2(MyBaseClassSettings settings) {
super(settings)
}
}
假设ARG游戏没有真正的相互关系(一个是数据库的连接,另一种是多数民众赞成分配线程任务的帮手,另一人做的部分实际的逻辑,另一个持有该类的地理配置......(只是例子))这个解决方案是否被认为是好的?
如果是这样,包装类的命名会是什么?
从实际上来说,您的解决方案是可以的。你可以用这种方式解决你的问题,这不会花你很多时间。话虽如此,如果您有时间,您应该重构代码并将该类拆分为多个类。
有10个依赖关系是你的班级做得很多的标志,并被认为是代码味道(看看this)。你的班级似乎有太多的责任,因此违反了Single Responsibility Principle。考虑Aggregated Services可以解决您的问题。
根据您的情况,您可以选择现在执行您的建议修补程序,稍后再进行重构。看看Technical Debt的概念。
至于班级的名字,你的建议是好的。另一个建议是MyBaseClassDependencies
。
是的,完全合理的解决方案和层次结构的常见习惯用法。
你的名字没问题。另一种命名模式是BaseParams
或BaseClassParams
等。
在这种情况下,访问这些字段的方法会更好。 像这样指定它们: this.db = params.db然后在没有变化的情况下访问它们 或将this.db的所有出现替换为this.params.getDb() – user844541
可能前者假设它有getters:this。 db = params.getDb()。这对你的其他代码来说会更传统和相似,包括子类。 – Fred
尽管这种方法没问题,但您应该检查所有参数参数是否没有共同之处......也许您会发现,您可以从“设置”中获取“数据库设置”,“用户设置” ,...并使用多个有意义的包装器。 –