I am working on a Java project that uses a dependency injection framework built by the company itself. The framework enforces the following naming convention: suppose you have a class Foo that depends on an interface called org.company.IBar:class Foo {   @Injection   private IBar bar;   ...}then the framework will search for a class called org.company.implementation.Bar, create a new instance of that class and then assign it to the attribute Foo.bar. The framework allows for some customization, though. In that @Injection annotation, you can declare your own factory, with which you can enforce your own conventions. But every time you want to use a certain factory, you will have to declare it explicitly in the annotation over the attribute to be injected.This strategy, however, will make your classes tightly coupled to each other, because when you declare a dependency on an interface, you are already committing to a given implementation. So, I decided to implement my own factory to manually perform dependency injection. It is basically a class that instantiates all application objects and wires them together. Each object has its scope (singleton or prototype) controlled by the factory. Think of a Spring IoC configuration file (but written in Java, instead of XML).My colleagues did not approve this decision. Their argument is that the factory I created has too many responsibilities and the instantiation of each object must be left to the framework. If you need to use another convention, you should create custom factories for each class (as described above). Definitely, according to them, there should not be one single factory where all the objects are instantiated.I strongly disagree with their argument. The factory has only one responsibility: creating the object graph. Should the need arise to modify that graph, there is only one class that will have to change. But I may be missing something here. What are the pros and cons of each strategy?
Which of these is the best strategy for dependency injection?
java;dependency injection
I agree that the model of a single default implementation, or one factory per class is too rigid.I see two potential problems with your approach:wiring up everything in Java makes configuration changes awkward - you need to recompile and redeploy (part of) the app every time,one factory to instantiate the whole object graph may be too coarse grained (depending on the size of the object graph). If the graph is huge, the factory logic becomes hard to maintain. This is why it may be better to have separate factories, although not necessarily one per class. Find a comfortable middle ground, by grouping together closely related / dependent classes.Single Responsibility Principle is good to follow, but IMO the main point of it is to create (and keep) classes of manageable size. Note that responsibilities have different levels of abstraction. What may look like a single responsibility on a higher level, is divided into several distinct tasks on a lower level. I can define a single responsibility for my class: satisfy the client's needs and create a classic God class, which clearly violates the SRP :-)