What is the difference between DI, Factories and locators?

Question

Already I asked about addiction injection. It is widely used. In my opinion it is even abused.

But I saw that in her place you can use Factories or locators. What would they be, what are the advantages and disadvantages of using each?

Answer 1

Dependency injection and Locator service (I’m assuming that with Locator you meant Service Locator) are ways of doing dependency inversion. Factories, in turn, care about instantiating objects without your caller worrying about their instantiation details (http://www.oodesign.com/factory-pattern.html).

Dependencies and inversion of control

When using dependency inversion, if you know which object is called in bootstrap time (more on this topic in paragraphs later), so you don’t have to worry about delay until the last moment to use the dependency. In such cases, the injection of dependency will make your job very easy. An example of where a dependency injection can be used is in special uses of multitone or even singletons, known a priori/statically as necessary.

There was a big project that I worked on unifying code. In the company, there were two products that were supposed to do the same thing, one webapp in GWT (with iBatis managing bank access) and an application mobile in Totalcross. Due to the incompatibilities between the Totalcross and JDBC database resources, and also that there are Java Apis that the iBatis used that do not exist in Totalcross, there was no way to share code that made the information rescue or what made the persistence. So the solution was to have an interface whose implementations would access the database and leave the environment that went up the application to insert the appropriate class. In the webapp, Spring took care of it using the interfaces @Component and @Autowired. At Totalcross, it was faster to do the hand injection using a class to perform the bootstrap of the application.

About the application lifecycle, I mentioned the bootstrap time. It’s not usually the most common term, but I needed to differentiate the time when the application is preparing to rise from the time when it’s actually actively running. This temporal separation is very much found, for example, when you are working on Unity, in which you prepare the scene using the MonoBehaviour.start to deal with some conformations of the environment you need to have before starting the game, but that it is not possible to inform in the time of construction of the object/ it is more practical to solve programmatically than in the scene editor; I like to imagine that the bootstrap time is analogous to the assembly of a board game, such as the distribution of territories and objectives in the War.

Environments of an application

Generally speaking, every application has the following environments:

1. Compile time, where the compiler can decide what is working; whether you can hold the value of a variable in Compile time, then means that you as a programmer must put the values in imperative mode;
2. Static code time, in the case of Java, annotation processing happens at this point; from a certain point of view, it is like a continuation of Compile time;
3. bootstrap time, that’s the time between pressing the button run and the application is actually running, the time of setup; spring dependency injection via XML fits here (also I believe that via injection @Autowired ); it is usually a part of the run time, but in this particular case I think it is notorious to highlight it;
4. run time, the environment in which the code is actually working and the application in the air; anything that exclusively can only be decided here is completely dynamic, coming from sources unrelated to the code.

An example of Locator service well used is in Squirrel, where the program does not know (nor has to know) a priori in which DBMS will connect, depending on the connection service registered in the JDBC to be able to make the contact successfully.

Dependency injection can also occur in the creation of objects (as in the case of Spring ). This injection can occur on demand, not necessarily a priori. In this case, the injection works as if bootstrap component, before it is in your run time proper.

Factories

Factories are objects that create objects, so the dependency inversion here occurs on another level. For example, to create connections of socket to move on to the class that handles HTTP connections, so that anyone who speaks HTTP does not have to worry about speaking _socket_ês, they just need to pass a constructor of sockets to do this. See SocketFactory of Java, which does just that.

The dependency injection pattern can be used in a way to use/need Factories.

What are the advantages and disadvantages of each of them?

Generally speaking, I always prefer where possible to use dependency injection, because with it I make the flow of the program more predictable. Not to mention that it’s easy to apply having a framework that does this. I always put predictability and ease as first choices.

Locators are for when you can consult from a common record what you need at that time. I find it particularly ugly, but functional. Also allows hotswaps for better performance or stability. For example, if you have a thread in parallel checking whether a newer image processing library has been placed and switching the return to the leitor de JPG for the newest desired.

Factories are usually used for a delayed creation of the object, for it to actually be created at the point at which it will be used.

---

UPDATE: DAGGER

Recently, in a request from a client at work, I had access to the dependency injector dagger.

Here are some sources on the subject:

• considerations and elucidations made by the Totalcross team (including): https://gitlab.com/totalcross/TotalCross/wikis/dagger
• official page: https://google.github.io/dagger/
• source: https://github.com/google/dagger

Basically, the dagger writ the work of bootstrap time in Java code, transforming the operations of this time Static code time. The idea of dagger is to remove the extra weight due to how to generate dependency injection in the Spring or in the Guice, transforming the work that is normally done by introspection (which is usually impossible in Compile time) for an analysis that is done in static code (i.e.: during compilation).

Supposedly, the dagger has as a final result the same as the injection of dependency handmade, but he manages it for you in a very good way.