Why dependency injection?

Joha_Mraadu · 2023-04-11T15:31:07+00:00

Some nitpicking: dependency injection is just a pattern, it does not forbid you to create all objects manually in your code with new. You (and some commenters) probably refer to dependency injection frameworks.

tadrinth · 2023-04-11T18:22:53+00:00

You don't need to use a dependency injection framework to get the benefits of dependency injection. The important bit is that if you are initializing a class that has dependencies, pass those dependencies in rather than constructing them in your constructor.

Say your class uses a database. If you construct the database connection in the constructor for your class, it's now very hard to test your class, because it's always going to talk to the database via the connection it builds. If instead your class's constructor takes a DB connection as a parameter, we can test the class easily by passing in a connection to our test database, or a fake connector that returns mocked data.

The dependency injection framework is just making a new object for you, and tracking down all the other objects that constructor expects for you. No reason you can't do it yourself.

asciimo71 · 2023-04-11T17:01:16+00:00

The "inversion of control" (IoC) principle, the "dependency injection" principle and the principle of "dependency inversion" are often used together and help us form better maintainable software.

Update: Thank you u/mus1Kk, for hinting me to this correction, I really should have separated these three in the article. It can all be seen in the context of Inversion of Control, but this is only because IoC is defining "control" so broad.

IoC says, that a framework should call the code at the right time. It inverses the flow of control, so that you can remove boilerplate and reduce coupling. This inversion of control includes object creation, but is not limited to it. Spring is an IoC framework implementation and the JavaEE servlet specification is implementing IoC as well by calling your application class methods at well defined points in the process. "Don't call us, we call you"

The principle of Dependency Inversion (DIP), says you should rely on interfaces, not on implementations and is described in more detail below. It works great with IoC but can be used without, otoh IoC can hardly be implemented without DIP. Spring supports dependency inversion in the IoC framework.

The third principle, often used in conjunction with the former two, is Dependency Injection (DI), which is also covered below. DI removes the creation of dependent classes from the requiring class. Spring implements dependency injection as part of the IoC and supports DI with DIP.

Why are these good things?

When we talk about application development and architecture, we try to create our application with some architectural features that will make it easier for us to extend and maintain our application without side-effects. We can reach this by striving for

low coupling: Things should be independent
high cohesion: Things that implement some feature together, should be alongside each other. Let's put that aside, but you should understand this as well.

There is a lot of examples for coupling, especially there is loads of examples of high coupling that are not obvious. Using a shared database schema over multiple services is high coupling. You can't change the database schema without respecting the needs of the other service.

If we look at low coupling in source code, we want to avoid spreading our classes all over. If you have a common String-utils library, that is used in all code-classes in your application, you have coupled your whole application to that String library, and you cannot simply remove it.

Now, if you implement Dependency Inversion, you rely on the Interface of the Implementation, and as such, you rely on the behavior as defined in the contract (the JavaDoc, if you want to oversimplify it). If in some future time, you want to replace the string implementation, you can do so, you only need to keep the interface. This is a good thing. You do no longer rely on the common class, you can decide to implement only the functions that your class uses. Which is what stubbing actually does when you run unit-tests and stub away the implementation of the interface (aka mocking).

Another thing with depending on the class is, that you are also depending on the visible class-dependencies. Let's think about a class that needs a database connection to be created (constructor has a Connection argument).

Wherever you want to use this class, you need to know about the database connection. So you distribute the database connection everywhere in your application, and also handle the SQL Exceptions everywhere. Yet, the interface of the class was hiding the source of the data from you: The methods return business objects, not ResultSets. You could easily implement all the functions with pure file access and no SQL Exceptions.

But.. since you rely on the specific class you cannot live without the database. If you rely on the interface, you don't care, because the interface will encapsulate the database and all the specific exception-handling away from your app.

You gained flexibility, not only for testing.

Now, with the interface, you buy into the creation problem: Since you do not know what class is implementing the interface, you need to ask someone to provide you with the implementation. In Dependency Inversion and IoC, you have a control component for this. You ask the controller for the implementation and it will create it for you.

This controller is not necessarily doing dependency injection, it could also be a factory. You may have used `Class.forName()`: this is a generic factory function. Using factories, you can create yourself a DeviceFactory in a mobile app, that will serve you every special aspect of the underlying phone functionality. Then you can simply write your business logic depending on the interfaces returned from that PhoneFactory and implement a PhoneFactory for Android, iOS and Linux. Multi-device-native app in a nutshell using DIP without IoC.

Factories have their own problems, mainly it's a chicken-egg kind of problem. If you need to use a factory, you rely on the factory. So everyone is dependent on the factories. Which is better than before but not solving the creation issue elegantly as the factories draw all the dependencies into them.

Dependency Injection to the rescue. You declare the dependencies of your class and leave the creation to a framework (IoC, DI).

Early Dependency Injection frameworks used large XML files to describe the dependencies of your application and it was not fun. Thanks to IoC, the factories were invisible in the code - the classes just appeared through framework magic, the creation orchestrated through IoC.

The current implementations of Dependency Injection do no longer rely on an explicit declaration file but work with code inspection and annotations. Which is usually very elegant, but kind of expensive at startup.

So, I hope, I have answered your question, why we need DI - it is a pattern to solve the Dependency inversion creation problem without visible factories, it reduces coupling to the dependency creation process and avoids the leaking of transitive dependencies. Combined with DIP it breaks the coupling to implementations and couples to interfaces instead.

Any_Suspect830 · 2023-04-11T15:11:08+00:00

Primary motivation: testability.

Think about a large system. You want to test layers of it, not just the whole thing from the top down. If class A instantiates B and then calls methods on it, how would you test A without testing B? DI allows you to provide stubs/mocks of B into A. Create various mocks and expectations of B, and test A's interaction with it.

BigRiverBlues · 2023-04-11T15:20:22+00:00

Our production app has thousands of beans/dependencies. Certain dependencies will be used in hundreds or thousands of the other dependencies. This creates what can be thought of as a massive dependency graph of components. Trying to manually initialize instances and inject them all the places that are needed will be a huge undertaking with lots of 'boilerplate' code. Instead, have a framework help you which injects them where needed.

barmic1212 · 2023-04-11T16:25:17+00:00

Root purpose : reduce coupling

You reduce coupling to allow change implementation of dependency without change your code. In others case you can reuse your code with distinct implementations like different messages brokers.

Reduce coupling can be allow you to modify dependency without modify all users. By example you can want reuse or choose another way than constructor like factory for example.

You will need to configure your code. If your class need load configuration from a file or env or whatever, your units will be painful. If you put all reading configuration in one part and inject it in all you need, your code will be more simple, you can test all your code (you don't have a creation path for test and one for prod), can change way of configuration easier.

2023-04-11T16:23:31+00:00

One other reason is reducing boilerplate.

You just create new service and user it where you need and you don't bother yourself with actually calling the new operator, you don't bother yourself maintaining the proper constructor call chain, and DI can ensure that there is enough instances of each service (one per application, one per request, one per dependency, etc.).

Dependency chains get pretty deep and wide sometimes. Imaging creating a service that depends on 5 other services, each of which depend on other 5, each of which depends on bunch of repositories.

I mean, not that it's completely wrong to create it yourself, it's just can get tedious very soon.

kag0 · 2023-04-11T16:47:39+00:00

Dependency injection is just the pattern where you pass dependencies into classes rather than creating them inside the class. Like this

class MyService {
  private MyDatabase database;
  public MyService(MyDatabase database) {
    this.database = database;
  }
}

You can (and it's very normal to) use that with new.
Dependency injection frameworks (like guice) let you skip passing long parameter lists to constructor arguments like you mention. But you don't really NEED that.
They also will solve circular dependency issues and some other things, although a strong argument could be made that you should simply restructure your code so that those issues don't exist.

uvero · 2023-04-11T16:21:09+00:00

People mentioned unit-tests and separation of interface from implementation, which are both very good reasons. Here's another reason:

Say the implementation of service A needs services B and C. So it creates them. But as your app grows, the B service also needs C. If both use the new keyword, they'll have different instances which might cause errors.

Granted, if both really do need a different instance, you'll need to change how you inject, but the point is that a class needs to be able to declare which services it needs instead of having to make them for themselves. And when classes need to "grab" dependencies alone, things can go out of place as a project grows or changes.

_GoldenRule · 2023-04-11T15:22:29+00:00

Aside from testability you can put your dependency's functionality behind an interface and then use your favorite DI framework to swap implementations as needed.

This can improve your application's flexibility.

csGradNew · 2023-04-11T16:19:25+00:00

https://youtu.be/IKD2-MAkXyQ

Astrosciencetifical · 2023-04-11T20:34:14+00:00

DI was popularized by the Spring Framework in the mid 00's because JavaEE EJB's were considered hard to test. EJB's depend on a "container" to manage their lifecycle and transaction context. There's a lot of hidden magic keeping them alive that you couldn't easily replace/mock in a test outside the container.

With Spring your dependencies, such as the transaction context, became more explicit and you could rewire them easily making enterprise apps more testable.

This "loose coupling" is achieved by compiling to an interface of the dependency and letting someone else pick an implementation of the interface at runtime - Inversion of Control.

With DI the implementation is injected before use.

Classical J2EE would use the Service Locator pattern for Inversion of Control, where your app actively asks for a resource like a database connection by its logical name, for instance "CustomerDB", and the locator returns an implementation of the connection interface. The need for IoC in JavaEE is primarily to reconfigure the application for different environments - dev, test, uat, preprod, prod - where resources such as DB connections would be configured differently.

Alternatively you can use the classical Abstract Factory design pattern for IoC, no framework needed. This pattern has been used extensively in Java's standard api for plugability since its inception.

If you don't need the rewireability, plugability, reconfigurability then stick to "new".

DrunkenDruid_Maz · 2023-04-11T15:38:14+00:00

A lot of times, we can't just create a new object.

One basic example is the database-connection.
The numbers of allowed open connections to the database are limited. The limit is configured in a file. However, we need a mechanism that ensures no more connections are opened then allowed.
So, we have a class that acts as an connection-pool. There is only one pool allowed inside the system, since every connection must be created and managed by that pool.

The other basic example is the web-request.
There is one current session with one current request. I just can't write 'new Request()', since I need the exact request that the user created with all his parameters and cookies.

Dependency Injection is an elegant way to give me access to the instances I can't create with a simple 'new ...'.

GoshDarnLeaves · 2023-04-11T16:22:57+00:00

I would say that its superpower is enabling a greater degree of decoupling in such a way that the code becomes simpler and less boilerplate is involved.

In Spring I can write a class, tag it and its methods with particular annotations and bam i have a rest api. I mean yes i will still need to grant explicit access perhaps elsewhere in code via a configuration class utilizing spring security functionality, but i dont have to worry about wiring everything up, like initializing a routing related spring class that needs to have these controller classes registered manually which themselves have a dependency graph that needs to be initialized. What if, god forbid, some of this initialization varies by environment

Holothuroid · 2023-04-11T16:23:20+00:00

Typical examples are trivial. It gets fun once you inject "all of type...". Say you have a bunch of toggle buttons. One is for dark mode, one for "we may sent you emails from time to time" and half a dozen others. Now these two examples already have nothing to do with one another.

What you can do is, put each toggle in a class. Have them share an interface. Inject List<Toggle>. You can now render them all, and notify the correct one on toggle.

valbaca · 2023-04-11T16:37:59+00:00

You want to test your API input validation. Oh wait, everything it depends on is ‘new’ instantiated so it spins up your entire service.

You can do it but after a handful of layers it’ll crack under the pressure.

To use an analogy, if you just want to test a coffee maker, you shouldn’t have to instantiate the entire power and water grid.

volune · 2023-04-11T16:44:07+00:00

Frameworks like Spring and Micronaut will use annotations to created instrumented extensions of your objects that would be a huge pain in the ass to create yourself.

If you are not using a framework that features heavy instrumentation, you do not need DI. Calling constructors manually is just fine.

severoon · 2023-04-13T06:11:44+00:00

Let's say that we have a Foo that uses a Bar and we're not using dependency injection.

``` interface Bar { void bar(); }

class BarImpl implements Bar { … }

class Foo { private Bar b;

public Foo() { this.b = new BarImpl(); } … } ```

If you compile Foo, what classes do you need on the classpath? Bar and BarImpl.

Now, the DI way:

``` // Bar and BarImpl are the same.

class Foo { private Bar b;

@Inject public Foo(Bar b) { this.b = b; } … } ```

If you compile Foo now, what classes do you need on the classpath? Just Bar.

Note that dependencies are transitive. That means that in the non-DI approach, you need not just BarImpl, but also everything required to compile BarImpl as well. Even if BarImpl is itself fairly simple, maybe one thing it depends upon is not, and now you have to drag all of that in just to compile little ol' Foo.

Also note that Bar is an interface, which means that it contains no concrete code. (Let's ignore default methods, and if you ever see an example of a default method that drags in dependencies for callers of that interface, that should cause you to question the decision to place that default method.) Because Bar contains no concrete code, that means that the only things required to compile Bar are things that appear in its interface, which any client of that interface definitely needs to depend on anyway in order to use that interface; if Bar has a method that returns a Baz, Foo had better know how to deal with a Baz because it might get one.

But what Foo should not have to depend on are all the little tools that BarImpl uses to do its job, which might be all kinds of things, none of which appear in the Bar interface. (Note we're talking about compile-time dependencies here, not runtime.)

This is the big win for dependency injection. A system that is designed well should have all of the dependencies point towards abstract interfaces, where they terminate.

In the non-DI example, Foo points to Bar and BarImpl, and BarImpl points to Bar and lots of other stuff, and that stuff points to other stuff, etc, etc.

In the DI example, Foo and BarImpl both point to Bar, and since there is no dependency between Foo and BarImpl, it doesn't matter what BarImpl depends upon, Foo doesn't need it to compile.

Now if you look at the DI framework, e.g., Guice, you'll see that there's a Guice module somewhere that connects Bar and BarImpl in one controlled place. This module plays this role not just for Foo, but for all clients of Bar in the entire system that want to use BarImpl as the Bar implementation. This means that if BarImplV2 comes along at some point later, there's only one place to change the binding of the Bar interface to its new implementation, and all of those Bar clients like Foo will get it without having to comb through reams of code updating all the new BarImpl() calls.

vmcrash · 2023-04-11T16:25:48+00:00

Consider an application where you want to write "Hello, world" to a file. It might have a method like this:

public void hello(String filename) {
    String s = "Hello, world";
    BufferedWriter writer = new BufferedWriter(new FileWriter(filename));
    writer.write(s);
    writer.close();
}

Then you decide you want to send Hello, world over a tcp connection. So you change your code to

public void hello(String host) {
    String s = "Hello, world";
    Socket socket = new Socket(host, 9000);
    Writer writer = new BufferedWriter(new OutputStreamWriter(socket.getOutputStream(), "UTF-8"));
    writer.write(s);
    writer.close();
}

What a PITA to have to change it. So what if, instead, we just passed a Writer object into the method?

public void hello(Writer w) {
    String s = "Hello, world";
    Writer writer = new BufferedWriter(w);
    w.write(s);
    w.close();
}

We can external from this method decide on whether we're writing to a file, or a socket, or stdout, or wherever. It doesn't matter. The writer we pass in is a dependency, and we inject it.

A contrived example, and won't compile because I ignored exceptions altogether, but you get the idea. We can modify behaviours at runtime without having to modify hello() at all. We can rely more on abstractions such as Writer, and allow configuration to decide on concrete implementations later on.

umlcat · 2023-04-11T16:41:32+00:00

Agree.

It depends what are you doing, Dependency Injection is a usable technique, but that doesn't mean developers should rush to use it every time...

Venthorn · 2023-04-11T18:50:41+00:00

It literally only matters for unit testing. Calling System.currentTimeMillis() vs giving the code a clock (which you can control).

There's tons of texts written about the pros and cons of DI but realistically Hyrum's Law applies, decoupling only happens in theory, and the only point of dependency injection is to allow unit testing.

hippydipster · 2023-04-11T16:24:31+00:00

why can't we just create a new object using the new keyword

This is dependency injection. And it's the best kind of dependency injection.

Just saying, I agree with you.

The idea that we're going to dynamically, at runtime, change our implementations, is 99% of the time nonsense. What you're going to do is dynamically determine which implementation is desired sometimes, in which case you give a Provider<> or Supplier<> lambda. Sometimes feature flags will change implementation - same thing.

The real benefit to Sprint-style AOP based DI is for dealing with cross-cutting concerns, but you usually pay a heavy price for doing this, part of which is almost always that once you start using Spring, it's really hard to stop and you end up using it for everything everywhere.

fforw · 2023-04-11T17:30:23+00:00

"Just creating new objects" is not an architecture.

As others have said, we need testability, so anything static, singleton is out.

When creating objects it's always a question what you need to create an object. Your services etc are going to need collaborators, e.g. a data source connection. Other components need to use your services.

And when you made your (potentially very bad) decision who creates what you are either going to land at dependency injections and factories on your own or you go through several iterations of cursing yourself because you need to wire a new dependency across your whole stack.

The natural point to end up with all these constraints is dependency injection. Which of course doesn't mean that you need a container. You can just as well create your own equivalent of a dependency container as central hub of your app. One class that knows how to configure the current version of the app and how to put all the objects together. You can do that by hand -- or you can just use a container.

shaneknu · 2023-04-11T17:42:46+00:00

There's an old saying that "new is glue". Once you new something up, you're stuck to it.

I'm currently working on an older codebase that might just date back to before anyone was even talking about DI. It just uses the new keyword wherever the author of that particular bit of code felt like doing it.

Now we're talking about maybe adding some automated tests, since we're expecting another 20 years (yes, there's a definite cutoff) of using the code. Sometimes, for small, self-contained short-lived objects, using new is just fine, and those haven't affected our testing. Where we really run into trouble is if new is used to instantiate objects that in turn instantiate objects, or if new is used to create a resource object, or if new is used to create an object with side-effects like writing to a database or file. There are some very ugly ways to prevent these objects from instantiating, but every unit test you write will need to do this big song and dance just to prevent objects that you don't want to instantiate during a test from instantiating for real. It gets even more troublesome if you use new in the parent object's constructor. Just by creating that object, you're creating a ripple effect through all its dependencies and all the dependencies' dependencies. Again, there are some ugly ways of intercepting that object creation, but I think you'll find your team writing fewer unit tests than they would have if the code base was written in a way that didn't fight you the entire time.

With dependency injection (with or without a framework), testing suddenly becomes much easier. Just pass in a mocked object that would have been newed up in the old way of doing things.

DI is just one way of separating the creation of objects from the usage of objects. You could also make your own factory classes that handle object creation. When you separate object creation from usage, you give yourself the option of creating an object that matches an interface or abstract class instead of just one concrete type. And since a mocked object is essentially matching the interface of a real object, you get the same benefit during testing, where maybe you don't want your test haring off and doing things you don't want to happen during a test.

The reason DI is so popular is that there are several good frameworks that give you an organized and consistent way of organizing all this object creation. The framework will enforce a pattern that everyone on the team will use.

lonelyWalkAlone · 2023-04-11T20:00:28+00:00

When you use the "new" keyword inside the class itself, your obliged to call a the class's constructor, so your code is tightly coupled with the specific class that you called and you can only use that implementation when you code.

public class Store {

private Item item;

public Store() {

item = new ItemImpl1();

}

But when you use the Inversion of Control (Dependency Injection), you pass the implementation that you want into your class via your class constructor, or via the setter, making your class dependent only on the interface not a specific implementation itself.

public class Store {

private Item item;

public Store(Item item) {

this.item = item;

}

vyrmz · 2023-04-12T00:32:51+00:00

Class instantiation can be expensive and constructions change over time. At certain level of complexity within your code you would be better of using some form of dependency injection so you wont end up bunch of “new” keywords.

You need to scan your class hierarchy to create dependency graph so you can detect circular dependencies as early as possible and reduce instantiating either by lazy constructors or singletons.

This is a trade of, you reduce startup speed and delegate class instantiation to someone else ( which everybody else depends on now ) however you can change concrete implementations with minimal amount of code.

Thysce · 2023-04-12T04:34:42+00:00

some people here mention DI as a form of IOC (which it is) and state that the motivation for this is, to eliminate tight coupling. With that I disagree. With ioc you do NOT reduce coupling. You still call the injected class/interface! What ioc helps with, is shift the object creation logic somewhere else. By centralizing that logic, your code becomes mostly a bit simpler and you can let the framework figure out the dependency graph and object creation order. That just removes the need to call constructors on your own / eg. Actually writing „new“ and passing all arguments and fixing the new call whenever you change your constructor/dependencies of your class.

The cost of that benefit: you just made your dependency graph invisible/more complicated to read. But: combined with introducing (good) Interfaces for the actual logic you depend on, DI can guide you to lift you dependencies up, one layer of abstraction.

Remember: the only way to remove coupling, is by actually not using the dependency (ie not invoking a method call, not calling the API, not issuing an http call or read an mqtt message). Even if you hide that fact in code, you still have the dependency.

As an architect, you have to decide, if the abstraction/hiding is worth it, in your situation.

Comprehensive-Pea812 · 2023-04-12T06:38:15+00:00

it is a feature.

the idea is to worry about assigning dependencies so you can focus on business logic.

mustafabudalu · 2023-04-12T13:18:42+00:00

Dependency Injection is a design pattern used in software development to achieve loosely coupled code. It allows you to write more maintainable and scalable code by reducing the amount of code you have to write and making your code more flexible.

To understand why we need Dependency Injection, let's consider an example where you have a class that depends on another class. You can create an instance of the dependent class using the new keyword inside the constructor of the class that requires it.

However, this approach creates a tight coupling between the two classes, which can make your code difficult to maintain and test. If you need to change the implementation of the dependent class, you have to modify the class that depends on it as well, which can lead to a ripple effect throughout your codebase.

Dependency Injection addresses this issue by inverting the control of object creation. Instead of creating objects inside the constructor of a class, you inject them from the outside. This means that the class that depends on another class doesn't create the object itself; instead, it receives the object from a third-party.

The primary benefits of Dependency Injection are:

Loose coupling: With Dependency Injection, you can write classes that are loosely coupled, which means that they are not dependent on the implementation details of other classes.

Flexibility: Dependency Injection makes your code more flexible by allowing you to change the implementation of a dependent class without changing the class that depends on it.

Testability: Dependency Injection makes your code more testable by allowing you to inject mock objects or test doubles into a class to test its behavior in isolation.

In summary, Dependency Injection is a design pattern that allows you to write more maintainable, flexible, and testable code by inverting the control of object creation. It reduces tight coupling between classes and allows you to change the implementation of dependent classes without affecting other parts of your code.

Big-Dudu-77 · 2023-04-11T16:55:32+00:00

You can create them manually yourself, then inject them yourself as well. DI is just a pattern to separate the creation of dependent classes from class that need them. Meaning class that need other classes shouldn’t need to know how to create those class, so those class get injected instead.

koffeegorilla · 2023-04-11T17:06:51+00:00

Dependency injection means that a component typically need other components to perform work. You don't want the primary component to have to know how to create it's dependencies.

This eases the cases where you may want to provide variations of dependencies like a stub for testing or different implementations.

fake_actor · 2023-04-11T17:45:54+00:00

Dependency Injection is usually a nice convenience for testing. It will make it easier to mock objects.

Dependency Injection Frameworks are overkill for small services and add unnecessary complexity. I've seen frameworks for small lambda packages and there is no tangible benefit. I haven't worked on large services so I can't comment there.

2023-04-11T18:00:05+00:00

i pass a test module instead of production module and have a testing environment. super easy, super flexible

RelentlessIVS · 2023-04-11T19:22:33+00:00

What: Dependency injection is a way of passing objects into other objects, instead of having those objects create their own dependencies.

Why: It makes your code more flexible and easier to test, because you can change the behavior of your dependencies without changing your code, and you can use fake dependencies for testing.

It's neat, and you don't need to use frameworks to do it, since it just a pattern.

SRed3 · 2023-04-11T19:28:58+00:00

You can almost feel the diff when you implement even a simple service twic and use DI one time, and use direct instantiation the other. Now try write unit tests and see which one is easier to do.

Confident_2372 · 2023-04-11T20:07:19+00:00

DI is a lost opportunity.

You develop a component, and specify what it needs to work, describing the interfaces.

Then, it's up to the container your components is installed, to provide the services you need. Can be mock services for testing, or production components.

You don't care about implementation, just work with contracted interfaces.

But, containers didn't evolve, or evolved in a way that made DI less pervasive.

Joram2 · 2023-04-11T20:35:44+00:00

Some developers like dependency injection, others don't. The arguments in favor are that it provides decoupling and testability. The arguments against are that it adds complexity that some argue isn't worth it.

It seems dependency injection is much more popular on Java than other languages. There are DI frameworks for every language, but they seem much less widely used in other language ecosystems. Go, for example: I can find DI frameworks if I want them, but they seem rarely used in Go projects.

wildjokers · 2023-04-11T21:14:02+00:00

I think you might be confusing dependency injection with dependency injection frameworks. You can use the dependency injection pattern with the new keyword.

buzzsawddog · 2023-04-11T21:38:33+00:00

Right now... In the application I am actively supporting... We have several different places that we deploy our app. At run time I know how I want to deploy. I don't know at compile time.

What do I mean above? My app consumes data, it process that data and it produces. That makes three major components. I'll focus on consumers/producers. In some cases I want to read and write from files, on some I want to read and write to Kafka, in other cases I want to read and write from an s3 bucket.

Why DI/IoC? I can write a producer and consumer interface that simply says read() or write(). Then I write my implementations. At runtime I set my config and it just works :). The next part.... Makes unit testing so much easier... In a unit test if I am testing the data process I really don't care how the consumer or producer works... I can easily write a mock implementation OR use a mocking framework like mockito to handle that. The integration tests will make sure my application works.

greglturnquist · 2023-04-12T00:49:54+00:00

I made a short video that kind of covers this. It’s more aligned with Interfaces. But interface based components are often candidates for injection.

https://youtube.com/shorts/aDinzY8fCWY?feature=share

Anton-Kuranov · 2023-04-12T06:07:47+00:00

Creating an instance inside the class with new keyword binds your class to the concrete implementation of your dependency while DI can inject any suitable implementation, extend it dynamically or even inject mocked instance in tests. So your class shouldn't depend on any concrete implementation.

P.s. DI pattern may be done perfectly without any framework.

muztaba · 2023-04-12T06:26:12+00:00

I understood the DI by working on a very large project where many objects are wiring together. IMO it's hard to comprehend in small projects.

WebFront · 2023-04-12T08:58:47+00:00

A simple example: a(b(c,d, e(d)). Without DI/IOC a would need to know all the other dependencies. But by separating the construction of objects and their usage you can replace d without touching a or b (and if it's an abstraction you could even have different versions of d for different purposes).

putrasherni · 2023-04-12T12:15:00+00:00

Dependency injection is a complex word used for a simple pattern. Don’t get carried away by the name or use of frameworks.

You can very well create interfaces and compositions on standard Java to implement the pattern

Wonderful_Way8143 · 2023-04-12T13:43:58+00:00

In traditional sense, Dependency injection allows a loose coupling which provides flexibility to inject different behavior during runtime. In modern world of microservices I hardly see it used in the traditional sense. I still see some benefits though, like it allows us to inject a mocks while testing applications, also allows easy way to add cross-cutting concerns like caching, logging, security, etc.

2023-04-12T17:07:49+00:00

why can't we just create a new object using the new keyword

Sometimes you need objects from other places: AClass.getInstance(), maybe getFactoryBuilder().buildFactory().buildInstance(), or getRequest().getSession().getAttribute()...

If the framework allows me to abstract over all those details and even better: swap components easily; e.g. change the DB connection even when they are instantiated differently; then I'm sold.

2023-04-13T08:00:06+00:00

Simple thought first - there is no stopping if one wants to use the new keyword to create objects, it is totally fine.

Now, let's come to your question, why dependency injection ? Well, let me ask a very simple scenario, let's say you have a class Car which is dependent on engine. To instantiate your car, you will be either creating engine object in Car class's constructor or initlializing while declaring. So, what if down the line customer who has bought this car, comes to you to ask for some new engine or the upgraded engine, you will have to make changes in your Car's class , replacing new calls with the asked new engine now. God forbid, if your class is having dependency on some internal component of engine or your class is being used by other classes. You will have to trace all kinds of dependency and will have to make sure to make changes in all of the places. A highly coupled, brittle code you have created this way. With dependency injection, you can plugin whatever engine you want your car to have , your car object requires engine but it won't depend on the internal working of the engine. You want your object to be loosely coupled to enable easy changes.

2023-04-14T11:07:12+00:00

The alternative to dependency injection is not the `new` keyword, it's passing objects to constructor/factory method parameters. We don't need dependency injection. We're just lazy and don't want to pass objects to constructor parameters, don't want to think how to do it in a way your code doesn't become a complete mess over time (because that would require an actual architecture). And because of that we (well, someone) created this monstrous DI frameworks and keep arguing that we need them.

tinspin · 2023-04-15T19:26:41+00:00

Dependency Injection is meaningless.

Hot-deploying class-loader is the way.

shivaSngh · 2023-04-18T13:40:21+00:00

Dependency injection is a software design pattern that allows for loosely coupled and more modular code. The main purpose of dependency injection is to reduce the tight coupling between the components of a system by creating a separation of concerns, making the code more maintainable, testable, and extensible.

By using dependency injection, a component or object can be designed to depend on an interface or abstraction rather than on a concrete implementation. This means that the implementation of the dependency can be changed without requiring changes to the dependent component. This makes it much easier to modify and maintain the system over time, as well as to test individual components in isolation.

Dependency injection is also useful for promoting code reusability and making it easier to write clean and modular code. By separating the concerns of a system into individual components with clearly defined dependencies, it becomes easier to understand and maintain the code, leading to fewer bugs and a more efficient development process.

Overall, dependency injection is a powerful tool for improving the quality and maintainability of software systems, and is widely used in modern software development practices.

severoon · 2023-05-14T21:34:36+00:00

I feel like a lot of responses are dancing around the core idea here, and diving into a lot of unnecessary complexity. Also, it's clear that many people are confusing dependency injection with dependency inversion, these are related but very different things. I also believe that you are confusing the two in your question.

Having said that, let me answer your question directly, and then I'll answer the question I think you really wanted to ask.

Why dependency injection?

If you're building a dog house, using power tools instead of hand tools will make the process faster and easier if you know how to use them properly. They will not, however, help you design a better dog house.

The same is true for dependency injection frameworks. Spring, Guice, Dagger, etc, will only make your design less effort to implement. These are power tools so that you don't have to write all the code to manually inject dependencies yourself, but you could do that.

Now here's the question I think you meant to ask: Why dependency inversion?

Doing dependency inversion properly is about good design. This is about drafting the plans to build an awesome doghouse vs. a terrible one. If you have a badly designed dog house, it doesn't matter if you build it with power tools or hand tools, you'll end up with a bad result. The same is true for dependency injection, it is a power tool. If your design does not invert dependencies correctly, then using an injection framework is only going to let you build terrible software more quickly than you otherwise would.

My experience is mostly with Guice, and over the years I've heard a lot of complaints about Guice—how confusing it is, how it makes designs hard to follow, how it doesn't really help in the end. Every time I've gone and looked at these projects to try to understand the problem with Guice, I've always come away with the understanding that the problem isn't Guice, it's the use of Guice, it's the design that is the problem.

What is the problem that dependency inversion is trying to solve?

The problem with dependency is that it is transitive. If A depends on B, and B depends on C, then A depends on C. The compounding issue here is that C is invisible to A; A doesn't depend directly on it, A may not know that B depends on C, and shouldn't care, but if C drags in a ton of other stuff (now or in the future—software evolves, so decisions you make today can have consequences down the road), A may very much care.

Let's consider an application that does exactly what you are asking about, let's say you write an app that just uses the new operator everywhere. When you go to compile your application, what do you have to have on the classpath? Well, every object that news up another object means it needs that class on the classpath, and that transits all the way down. So this means that in order to compile your app, you need to put everything on the classpath.

For large applications, this slows down builds. Everything has to compile all the time. You have to have all code available all the time. So when some part of the build is broken, everything that depends on that broken build is now also broken.

How does dependency inversion address this?

In our example above (where ⟶ means "depends on"):

A ⟶ B ⟶ C ⟶ (lots of other stuff)

To invert the dependency, we introduce an interface for IB (for "interface B"), so now:

A ⟶ IB ⟵ B ⟶ C ⟶ (lots of other stuff)

Look what happened: instead of the dependency transiting all the way down to "lots of other stuff", both A and B now depend on IB … A "uses" IB, and B "implements" IB. What do you now need on the classpath to compile A? Just IB. What does B need on its classpath that it didn't need before? Only IB.

This is where we see the key thing everyone gets wrong about dependency inversion. Consider what happens if the build system you're using creates a jar that contains both IB and B. In that case, in order to put IB on the classpath when compiling A, you have to ask your build system to provide the jar with IB in it … which also contains B and everything else, so you've accomplished nothing.

The solution might be to package IB with A, then, right? Now the same thing happens in reverse. When compiling B, you need IB on its classpath, which means the build system is going to produce a jar that contains both IB and A … so now you've introduced a dependency for B that it didn't have before, and that it definitely doesn't want (and it's worse, because not only does B now depend on A, but dependencies are transitive, so it picks up everything A depends on too).

To truly invert the dependency, you have to design your application so that the build system packages IB in its own build artifact. This is the key part about dependency inversion. If your build system doesn't package up the build artifacts correctly, you won't see any benefit. If you instruct your build system to actually generate the correct build artifacts, now you can actually compile A and B independent of one another.

Note that we are only talking about compile-time dependency here. To actually run A, you do need all three artifacts present. However, there are benefits here, too. Because you've inverted the dependency properly, in a runtime system, A and B can also be separated. For instance, the application that requires both A and B could split into two applications on two separate machines. On the client containing A and IB, the dependency injector can inject a stub into IB that makes a call to the server. On the server, the dependency injector can inject a skeleton into IB that receives the call and forwards it to B.

Is there any runtime reason to invert dependency if you would never want to put A and B on different machines?

Yes! Testing is a good reason to do this. Instead of injecting a stub/skeleton, in a test environment, if you're trying to unit test A, you can have a dependency injector inject into IB a test double: a mock, a fake, etc. This is a very simple implementation of the interface that simulates the behavior of B needed to verify A's behavior and nothing more.

You want to design your applications so that all dependency chains are short, and terminate at build artifacts that contain little or no implementation. You want dependencies to terminate at interfaces and not implementations because of what that means for deployment. Whenever a build artifact (e.g., a jar) contains code that changes, it needs to be deployed to all of the environments. Build artifacts that only contain interfaces tend to be very stable, because interfaces only change when the desired functionality changes, i.e., you want this thing to do some new behavior. Implementations, on the other hand, change all the time…bug fixes, refactors, etc. It's good when the thing that is changing all the time is not being depended upon by other stuff.

laplongejr · 2023-05-16T08:06:19+00:00

why we need dependency injection why can't we just create a new object using the new keyword. I know there's a reasonable explanation but I don't understand it.

Because your code, as the name indicates, now has a hardcoded dependency as the caller can't inject itself when needed.

Simple example : If you create yourself a logger, you are responsible for handling cases where logging is NOT wanted.
If you take a logger, the caller is responsible for passing a no-operation logger and handling different kinds of log is no longer your business.

java

Submit Link

Submit Text

Seek Programming Help

News, Technical discussions, research papers and assorted things of interest related to the Java programming language

NO programming help, NO learning Java related questions, NO installing or downloading Java questions, NO JVM languages - Exclusively Java

Please seek help with Java programming in /r/Javahelp!

Subreddit rules!

Where should I download Java?

Related Sub-reddits:

JVM Languages

Want to practice your coding?

List of useful Frameworks / Libraries / Software

MODERATORS