【发布时间】:2015-06-18 16:04:56
【问题描述】:
我最近开始从事一个 Java 项目,该项目已经由一个团队开发了超过 3 个月的大量代码库。我注意到在很多地方,他们直接在客户端对象的构造函数中实例化了一些对象,而不是使用依赖注入。我想将对象构造重构为工厂并使用一些注入框架。
我创建了一个工厂,它本质上是一个做new <type(some params here)> 的班轮。这里没有什么花哨的——没有单例,没有静态工厂模式。只是一个 newInstance() 方法,它返回一个新的依赖实例。
在代码中显示一些东西:
class A { A() {
B bobj = new B(); // A and B are coupled directly
}
}
我想将其重构为:
BFactory {
newInstance() { return new B(); // return B implementation }
}
class A {
A(BFactory factory){
B bobj = factory.newInstance(); // A does not know about B impl
}
}
我的论点是,不应在代码中的任何地方创建对象,除非在为此目的的工厂中创建对象。这促进了松散耦合,否则您将两种类型紧密耦合。一位资深成员(我正在尝试重构的代码的作者)认为单班轮工厂的设计过于复杂。
是否有关于管理这个问题的模式的权威建议/参考?可以用来决定哪种方法更好以及为什么?
【问题讨论】:
-
我的论点是“如果它没有坏就不要修复它。”使用工厂方法获得的耦合丢失不值得花费时间或风险(错误)来触及代码库的每个部分。现在就开始吧。
-
您的帖子能否通过一个简短的示例来说明您正在谈论的内容?您的描述可以有几种不同的解释方式。
-
我会将@markspace 的评论稍微更改为“等到它坏了再修复它。”。如果并且当您需要使用工厂方法进行更简单和更清洁的更改时,请重构该类的构造。如果某项工作正常且不需要更改,请不要理会它。
-
我认为这个问题不应该因为主要基于意见而被关闭。 OP询问他的做事方式是否正确。我不知道答案是取决于你的情况。
-
仅在需要时使用松散耦合,如果工厂可以创建该接口/类的多个实现,那么您应该使用工厂来创建它们,如果它是一个对象,则不要创造生命通过向其中添加工厂变得复杂。