为了账号安全,请及时绑定邮箱和手机立即绑定

如何避免依赖注入构造函数的疯狂?

如何避免依赖注入构造函数的疯狂?

饮歌长啸 2019-06-24 10:33:10
如何避免依赖注入构造函数的疯狂?我发现我的构造器开始像这样:public MyClass(Container con, SomeClass1 obj1, SomeClass2, obj2.... )随着参数列表的不断增加。既然“容器”是我的依赖注入容器,为什么我不能这样做:public MyClass(Container con)每节课?缺点是什么?如果我这样做,感觉就像在使用一种美化的静电。请分享你对国际奥委会和依赖注入疯狂的想法。
查看完整描述

3 回答

?
冉冉说

TA贡献1877条经验 获得超1个赞

如果您使用容器作为服务定位器,您是正确的,它或多或少是一个美化的静态工厂。有很多原因我认为这是一种反模式。.

Constructor注入的好处之一是它违反了单一责任原则显而易见。

当这种情况发生时,是时候对外观服务的重构..简而言之,创建一个新的、更多的粗粒接口,它隐藏了当前需要的一些或所有细粒度依赖项之间的交互。


查看完整回答
反对 回复 2019-06-24
?
交互式爱情

TA贡献1712条经验 获得超3个赞

我认为您的类构造函数不应该引用IoC容器期间。这表示了类与容器之间的一种不必要的依赖(IoC试图避免的依赖类型)。


查看完整回答
反对 回复 2019-06-24
?
阿晨1998

TA贡献2037条经验 获得超6个赞

传递参数的困难不是问题。问题是你的课做得太多了,应该更多地分解。

依赖注入可以作为类变得太大的早期警告,特别是因为传递所有依赖项的痛苦越来越大


查看完整回答
反对 回复 2019-06-24
  • 3 回答
  • 0 关注
  • 772 浏览

添加回答

举报

0/150
提交
取消
意见反馈 帮助中心 APP下载
官方微信