Java对象创建模式和设计

Question

我最近开始从事一个 Java 项目，该项目已经拥有由一个团队用 3 个月多的时间开发的相当大的代码库。我注意到在很多地方，有些对象直接在客户端对象的构造函数中实例化，而不是使用依赖注入(inject)。我想将对象构造重构为工厂并使用一些注入(inject)框架。

我已经创建了一个工厂，它本质上是一个单一的类轮做事 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
  }
}

我的论点是，不应在代码中的任何地方创建对象，除非是在为此目的而设计的工厂中。这促进了松散耦合，否则你将这两种类型紧密耦合。一位资深成员(我正在尝试重构的代码的作者)认为 one liner factory 是一种过于复杂的设计。

是否有关于管理此问题的模式的权威建议/引用？可以用来决定哪种方法更好以及为什么？

Answer 1

One senior member ( the author of the code I am trying to refactor ) feels that the one liner factory is a over-complicating design.

这看起来像是您问题的症结所在，而不是您是否应该重构代码，所以让我们回答它而不是偏离实际问题。如果我们考虑您在代码中提供的示例，我同意您同事的看法。您不应该为每个要注入(inject)的依赖项创建一个工厂类。您试图实现的目标没有错，但您尝试实现它的方式有点矫枉过正。

您要么依赖于知道如何创建每个依赖项的 Factory 类的层次结构，要么依赖于实际类本身并拥有一个可以连接的 Container对象一起为你。

选项 1:依赖于通用工厂

class A {
   B bobj;
   C cobj;
   A(Factory factory){  
     bobj = factory.createB(); 
     cobj = factory.createC();
   }
}

方式二:直接依赖依赖

class A {
   B bobj;
   C cobj;
   A(A a,B b) {  
      this.bobj = b;
      this.cobj = c
   }
}

然后您可以创建一个知道如何将对象连接在一起的 Container 类:

class Container {
    public static B createB() {
        return new BImpl();
    }

    public static C createC() {
         return new CImpl();
    }

    public static A createA() {
        return newAImpl(createB(),createC());
    }
}

上面给出的例子太基础了。在现实世界中，您通常会有一个更复杂的依赖关系图。这就是 DI 框架派上用场而不是重新发明轮子的地方。如果您的最终目标是开始使用 DI 框架，则可以选择选项 2，因为 DI 框架通过向其客户端提供依赖项而不是请求它们的客户端代码来实现控制反转。