#Why use dependency injection?

1 messages · Page 1 of 1 (latest)

vestal kiln
#

Why use dependency injection? Is that pattern used so that programmer doesn't need to write a lot of time SomeClass someName = new SomeClass(), so instead some form of dependency injection, like for example constructor type of dependency injection is used?

runic fossilBOT
#

<@&987246841693360200> please have a look, thanks.

runic fossilBOT
#

While you are waiting for getting help, here are some tips to improve your experience:

Code is much easier to read if posted with syntax highlighting and proper formatting.

If nobody is calling back, that usually means that your question was not well asked and hence nobody feels confident enough answering. Try to use your time to elaborate, provide details, context, more code, examples and maybe some screenshots. With enough info, someone knows the answer for sure.

Don't forget to close your thread using the command </help-thread close:1027500463647621170> when your question has been answered, thanks.

#

Here is an AI assisted attempt to answer your question 🤖. Maybe it helps! In any case, a human is on the way 👍. To continue talking to the AI, you can use </chatgpt:1108714622413963314>.

#

dependency is passed to the class or method?

Dependency injection is a design pattern used in software development to achieve loose coupling between components and improve code maintainability, testability, and reusability. It allows for the inversion of control, where dependencies are provided externally rather than being created internally within a class.

Here are some reasons why dependency injection is beneficial:

  1. Decoupling: Dependency injection helps decouple the components by removing the responsibility of creating dependencies from within a class. This allows for easier modification and testing of individual components without affecting others.

  2. Code Reusability: With dependency injection, dependencies can be easily reused across different classes or modules. This promotes code reuse and reduces duplication.

  3. Testability: By injecting dependencies, it becomes easier to mock or substitute those dependencies during unit testing. This enables isolated testing of individual components without relying on their actual implementations.

  4. Flexibility: Dependency injection provides flexibility in configuring and managing dependencies at runtime. Different implementations can be easily swapped without modifying the code that uses those dependencies.

  5. Maintainability: With dependency injection, changes in one component do not require modifications in other components that depend on it. This improves code maintainability as modifications are localized to specific classes or modules.

  6. Scalability: Dependency injection facilitates scalability by allowing new components to be added without modifying existing code extensively. New dependencies can be injected as needed, making the system more adaptable to change.

In summary, dependency injection promotes loose coupling, improves testability and maintainability, enhances code reusability, and provides flexibility and scalability in software development projects.

worthy gorge
#

Hyia!

#

what the Ai said

#

and if you still have issue, then welcome

sudden dove
#

@vestal kiln This video is a really good explanation

vestal kiln
vestal kiln
sudden dove
#

The AI was incoherent

vestal kiln
#

@sudden dove Can you explain decoupling part?

#

I watched that video that you linked but with watch again

low bramble
#

Say you have application that runs over a database, you do not know exact implementation, so whichever class wants to use that database has to figure out what implementation of DB you are using right now, then know where to get connector to that DB...or someone in the application could just know that and give...dare I say inject, that connector to that class and it needs to know jack shit about the actual DB

sudden dove
#

the DI part is just "pass things as arguments"

#

instead of "get things from global fields" or other options

#

it has too complicated a name for such a simple concept

#

makes people think its more involved than it is

low bramble
#

This stuff falls under broader concept of Inversion of control. whereas it is (disputably) better to give control over dependencies to outside framework and have actual classes fucus on their problems

vestal kiln
vestal kiln
low bramble
wispy valley
wispy valley
#

"passing as argument" is over-simplified. that would suggest that all method arguments, anything thats passed as an argument, relates to DI

#

to understand DI, you first have to understand what a dependency is. once you understand dependencies, you can focus on the injection part

vestal kiln
sudden dove
#

it is enabled by it

#

but its more like, doing other things takes away your ability to

sudden dove
wispy valley
#

argument passing is too much of an oversimplification

vestal kiln
#

I don't understand what you mean exactly by enabled, but I think that I see how it relates to decoupling - like not concrete type is initialised but something that is passed

sudden dove
#

and you are therefore "decoupled" from the logic of how things are stored

wispy valley
sudden dove
#

if you don't take it as an argument, like you take it from a global variable, then you are "coupled" to that one implementation

wispy valley
#

in object orientation, a dependency would be something that the object requires in order to work properly

vestal kiln
sudden dove
#

Decoupled

void doThing(StorageService storage, String data) {
   if (f(data)) {
       storage.store(data);
   }
}

Coupled

static final StorageService STORAGE_SERVICE = new AWSStorageService();

void doThing(String data) {
   if (f(data)) {
       STORAGE_SERVICE.store(data);
   }
}

Decoupled

class ThingDoer {
    final StorageService storage;

    ThingDoer(StorageService storage) {
        this.storage = storage;
    }

    void doThing() {
       if (f(data)) {
           this.storage.store(data);
       }
    }
}

Decoupled in one way, Coupled in another

class ThingDoer {
    final S3Client s3;

    ThingDoer(S3Client s3) {
        this.s3 = s3;
    }

    void doThing() {
       if (f(data)) {
           this.s3.store(data);
       }
    }
}
#

and your goal isn't and shouldn't always be maximal decoupling

#

you can be more or less decoupled based on what you pass as arguments

#

but passing things as arguments is the key

wispy valley
sudden dove
#

sure, that works too

#

depends on whether you actually have more than one thing which fills the role

#

or presume you might

#

a "DI Framework" is something that automatically passes things as arguments

wispy valley
#

doesnt always pass as arguments though. could be field injection

sudden dove
#

technically also there are more ways to "inject a dependency" like setters

#

but those are dumb

#

and morally equivalent once the thing is "Ready to Use"

#

i.e. the difference between

var thing = new Thing(dep);

thing.operation();

and

var thing = new Thing();
thing.setDep(dep);

thing.operation();

and

var thing = new Thing();
thing.dep = dep;

thing.operation();
#

pretty insignificant in the scope of things

#

the last 2 are just "you need to do more things after the constructor before being able to use the thing"

#

and thats just for when you make an object

worthy gorge
vestal kiln
worthy gorge
#

👍

viral flame
#

Sometimes names matter. Just by changing names might make stuff "click"

#

I love the name Configurable Dependency more.

#

Dependency could perhaps also be renamed to just a member of the class that the class instance needs to work as intended.

#

Configurable member 😄

#

your class Car needs an engine. Car.drive() has a engine.start() call inside of it that is not seen from outside.

#

so you car = new Car(coolEngine); car.drive(); makes go brrrrrrrrrrrrr.

#

you want a better car?

#

car = new Car(awesomeEngine); car.drive(); makes go vroooom Vrrooooom!

#

So Car doesn't need to change. Still called same way, but inner workings work differently based on what you "inject" into it.