编写自己的依赖注入

时间:2013-12-03 14:43:52

标签: java spring dependency-injection

我们正在开发一个应用程序。该应用程序将部署在专有的事件处理引擎中。对于DI,我们不应该使用任何api如弹簧核心。还没有专有的DI框架。所以我的想法是写一个简单的。

任何人都可以提供一些意见。

我的想法是编写一个包含静态方法的工厂类。静态方法将返回我们想要的类的实例。现在我们只想要一个实例。我假设下面的代码

public final class MyFactory {

    private static ClassA classA = new ClassA();
    private static ClassB classB = new ClassB();

    private MyFactory() {
        throw new CustomException("Cannot create instance");
    }

    public static ClassA getClassAInstance() {
        return classA;
    }

    public static ClassB getClassBInstance() {
        return classB;
    }
}

稍后我会像这样使用它

public class SomeRandomClass {

    private ClassA classA = MyFactory.getClassAInstance();
}

我看到的其他事情是我不需要测试ClassA和ClassB。测试SomeRandomClass将涵盖ClassA和ClassB。因为静态内容总是先加载。因此,在测试SomeRandomClass时,我总是有ClassA实例。因此,在SomeRandomClass中的某个方法上编写junit将调用ClassA中的方法。这好吗?

这是我正在做的事吗?我可以改善吗?

1 个答案:

答案 0 :(得分:2)

首先,工厂API不应该像这样直接引用具体的类实现。它有点挫败了目的。如果不重新编译,您将无法更改具体类,并且您将无法执行诸如对接口进行测试和开发的操作。

然后,假设你想要单身人士(这不是你的例子的写法),你需要确保你的工厂方法在他们如何产生单身人士方面是线程安全的。

您应该至少让工厂返回真正的单例接口实例。然后,您可以实现某种配置系统并使用Java反射API来确定应在运行时创建哪些具体类。这也使您能够执行诸如对接口进行测试或开发的操作。

这不是DI。还有更多内容,它在可读性/可写性/可配置性/可维护性方面具有远远超出工厂所能提供的优势。我不确定为什么使用Spring会成为专有软件的问题。 AFAIK Spring的许可证不强制代码是开源的或免费的......