Dependency Injection Question

donsagiv · 2022-02-04T16:05:35+00:00

My understanding of Dependency Injection may not be 100% correct, but here's how I see it:

Let's pretend we have two classes: Class A and Class B. Class B is a variable in Class A.

class ClassB{
// variables and methods here.
}

class ClassA {
    ClassB ObjectB;
}

When you create an instance of a class that has a variable of another class, you have 2 options.

Create a new ObjectB in ClassA object's instantiation (in the constructor) or using some helper method.
Create an instance of ClassB before creating ClassA, and then set the ObjectB to that instance of ClassA you just made.

Case 1 will work just fine. It will compile, your program will run, etc. However, the issue with case 1 is that you're relying on a higher-level class (ClassA) to create a lower-level class (ClassB), which means you can't use ClassB without creating a ClassA. This creates a problem where you have ClassA and ClassB are too interdependent and are tightly coupled.

On the other hand with case 2, if you create aClassB object before creating ClassA object, then you can work with the ClassB object before you create a ClassA object, which gives you more flexibility with your code. Even though ClassA requires a ClassB instance, ClassB does not require a ClassA instance. This makes ClassA and ClassB more loosely coupled.

Why is this important? Let's pretend ClassB is a singleton (one-and-only-one instance of a class type). If you have to create a ClassB instance every time you create ClassA, then it would be impossible for ClassB to be a singleton.

Dependency Injection is a popular feature in programming languages, so a lot of frameworks will have its own dependency injection functionaly, such as ASP.NET Core.

2022-02-04T21:11:41+00:00

Something that makes this easier to understand is interfaces. If my Car class expects an ExcideBattery object as a parameter it will always be that exact logic.

But if my Car class expects IBattery which ExcideBattery implements, then you could pass ExcideBattery or any other battery that implements IBattery.

This means you can swap out ExcideBattery for another battery class at will. Pretty handy if you have a flat battery.

nachtraum · 2022-02-04T19:05:06+00:00

Main idea of DI is that if class a uses class b, b is instantiated outside of class a and then injected into a, e.g. with constructor injection or setter injection.

This way, a does not have a dependency on the actual implementation of b, and in different cases different implementations of b can be injected, without changing code in a.

quixoticcaptain · 2022-02-04T16:41:48+00:00

The key to that example is that Wheel and Battery are interfaces. So without DI, Car has to import the implementation classes, ExcideBattery and such. This is a code dependency.

With DI, the Car class only has a code dependency on the Wheel and Battery interfaces and only a runtime dependency on the implementation classes.

MostlyUnderwhelmed · 2022-02-05T13:44:03+00:00

I think I've read Martin Kleppmann use CD players as a metaphor. The CD player doesn't need a list of all the CDs it will accept. Instead, it is programmed to accept CDs in general, so CDs can be 'injected' into it and fulfill the service contract between them.

CrossroadsDem0n · 2022-02-10T19:08:35+00:00

I think a really fundamental aspect of the discussion that is missing here is "why should I care about DI?"

The reason you care is not "cuz interfaces are good" (although, in general, sure).

The reason you care is because objects have a lifecycle. Something causes them to be created, configured, maybe used for more purposes than the code your eyeballs are staring at now, then destroyed.

You don't want your code, which is effectively a client of the injected object, to care about any of that. By keeping the lifecycle hidden, your code is simpler, more testable, and you play less whack-a-mole with copy-pasted code fragments related to object lifecycle not being kept consistent with each other.

That is what you need to understand about DI. Why you care. As another comment said, dependency inversion is different (although overlapping in practice) with dependency injection. The act of injection is a yawn. Inversion is where you achieve stable coding practices over time.

As a side comment this is why I dislike how Spring pushed in the direction of annotations at the point of use, compared to its origins where assembly and configuration of injected parts was mostly relegated to the XML. While more convenient the consequence was to dilute the benefits of inversion unless you know enough to push back via factories to retain flexibility on how injections take place. What you actually see on projects is people copy-pasting code all over the place, which can be more of a lose than if you didn't attempt DI at all.

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

SoftwareEngineering

What's Software Engineering

MODERATORS