所以让我们假设这个构造函数(当然这不是一个工作或实际的代码,因为我不允许在这里发布真正的代码)
public ClassA(ClassB b,ClassC c,ClassD d,ClassE e,ClassF f,ClassG g,ClassH h,ClassI i) {
this.b = b;
this.c = c;
this.d = d;
this.e = e;
this.f = f;
this.g = g;
this.h = h;
this.i = i;
}
我已经阅读了Martin Fowler的关于重构的书,其中有一个具有很多参数的方法是一个代码气味,不应该发生.
我的问题是：当我们在谈论DI时,这样可以吗？是否有更好的注入依赖方式,而不会破坏Martin Fowler的规则？
我知道我可以通过属性传递依赖关系,但这可能会导致错误,因为没有人真的确定应该通过什么来使类工作.
编辑
感谢您的所有答案.我将尝试演示一些A类依赖：
1 – 访问数据库的类
2 – 另一个类访问另一个数据库(是的,我需要对两个数据库执行操作)
3 – 通过电子邮件发送错误通知的课程
4 – 加载配置的类
5 – 作为一些操作的定时器的类(可以避免这个)
6 – 具有业务逻辑的课程
还有许多其他的我想要摆脱,但是那些真的是必要的,我没有看到任何避免它们的方法.
编辑
经过一些重构,我有7个依赖关系(从10开始).但我有4个DAO对象：
CustomerDAO
ProcessDAO
用ProductsDao
CatalogDAO的
是否正确创建另一个类叫做MyProjectDAO并将这些DAOS注入到它上面？这样我将只有一个DAO类可以聚合项目的所有DAO对象.我不认为这是一个好主意,因为它违反了单一责任原则.我对吗？
解决方法
关于你的最后一句话的注释：这样的顺序依赖也可以是一个代码的气味,所以很可能不要在你的界面中公开它.实际上,考虑到订单要求是否因为需要以特定的顺序进行操作(这是算法或协议的复杂性),还是因为您已将您的类设计为相互依赖.如果复杂性是由于您的设计造成的,重构可能会消除有序依赖.
如果你不能重构(复杂性是必不可少的,你手上有一个可怕的协调问题),那么你可以抽象丑陋,并让这个类别的用户被屏蔽(建设者,工厂,注射器等).
编辑：现在我已经考虑过了,我不相信你的算法或协议的基本复杂性不能被抽象出来(尽管可能是这样).根据您的具体问题,可以通过策略模式或观察者模式(事件侦听器)更好地解决这些依赖类的操纵的相似之处.您可能必须将这些类包装在类中,使其适应与当前暴露的接口略微不同的接口.你必须评估在这个怪物类中的代码变得更加可读(yay)的折中,牺牲了多达10个类的项目(boo).
我还想提出一个附录来抽象这个类的构造.看起来重要的是依赖于这个类的任何类都使用依赖注入模式.这样,如果您使用建筑工厂,注射器等,您不会意外地剥夺使用DI图案的一些好处(最重要的是我可以用替代模拟物体进行测试) .
编辑2(根据您的编辑)：
我的第一个想法是“什么,没有伐木依赖？
