Write own dependency injection

Question

we are developing an application. The application will be deployed in a proprietary event processing engine. We are not supposed to use any api such as spring core for DI. There are not proprietary DI frameworks yet. So the idea is to write one and a simple one.

Can any one please provide some inputs.

My idea is to write a factory class which has static methods in it. The static methods will return instances of the classes we want. For now we only want a single instance. I am assuming the below kind of code

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;
    }
}

Later I will use it like this

public class SomeRandomClass {

    private ClassA classA = MyFactory.getClassAInstance();
}

Other thing I see is I need not test ClassA and ClassB. Testing SomeRandomClass will cover ClassA and ClassB. Because static content is always loaded first. So while testing SomeRandomClass I always have ClassA instance in it. So writing a junit on some method in SomeRandomClass will invoke methods in ClassA. Is this good?

Is it the right way I am doing? Can I improve it even?

*Why* are you supposed to reinvent a very complicated wheel instead of using working, tested, and understood frameworks? — chrylis -cautiouslyoptimistic-, Dec 03 '13 at 14:45
Try to look at the code behind Guice - yes it is complex. But its usage is simple, just like CDI/Weld. That's why it is better to use what already exists. The thing is that in what is presented in this thread so far, I see no real reason to actually apply dependency injection just yet. Dependency injection is not a drop-in replacement for object instantiation. — Gimby, Dec 03 '13 at 14:51
A "simple" DI would be as simple as doing a `forName` on a string value somewhere. What *specific* requirements do you really have? — Dave Newton, Dec 03 '13 at 15:47
[Here's a 25 line DI implementation](http://stackoverflow.com/questions/15715978/simple-dependency-resolver/15717047#15717047) that might give you some inspiration. It's for .NET, but shouldn't be very hard to port to Java. — Steven, Dec 03 '13 at 16:30
What you are doing with the `MyFactory` is called the Service Locator pattern; it is considered to be an [anti-pattern](http://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Pattern/). You should use constructor injection instead. — Steven, Dec 03 '13 at 16:32
@AndreyChaschev & chrylis I dont know the reason why we are not supposed to used any DI frameworks. I have encountered Guice while using GWT framework. I suggested Guice also. — Krishna Chaitanya, Dec 04 '13 at 02:30
One of the reason we are not supposed to use any DI framework is because our event processing engine is evolving still. We only can add listener classes in the engine. We cannot add any class something similar to a servlet listener so that on startup we can initialize the DI. — Krishna Chaitanya, Dec 04 '13 at 04:32

reblace · Answer 1 · 2013-12-03T15:42:08.820

For starters, the factory API shouldn't reference the concrete class implementations directly like that. It kind of defeats the purpose. You won't be able to change the concrete classes without recompiling and you won't be able to do things like stubbing out interfaces for testing and development.

Then, assuming you want singletons (which is not how your example is written), you'll need to make sure your factory methods are thread safe in how they produce the singletons.

You should at a minimum have your factory return true singleton instances of interfaces. Then, you could implement some kind of configuration system and use the Java reflection API to determine which concrete classes should be created at runtime. This will also enable you to do things like stub out the interfaces for testing or development.

This isn't really DI. There's a lot more to it and it has benefits in readability/writability/configurability/maintainability that go far beyond what a factory can provide. I'm not sure why using Spring would be a problem in proprietary software. AFAIK Spring's license doesn't force code to be open source or free...

Write own dependency injection

1 Answers1