Dependency Injection is a shit!
-
Continuing the discussion from Programming Confessions Thread:
In a nutshell, instead of having your classes go out and find the tools they need to do their job, you hand them the tools they need to do their job, usually at object construction time. Which means if you want to use a Tool 2.0, or a Mock Tool, later on, you can do that without making a change to the class itself, just the consumer who wants to use your class with Tool 2.0.
Right; that makes no sense to me, though.
My classes don't need "tools" to do their jobs, they are tools to do a job. You don't hand them "tools" at creation time, you hand them context. Classes aren't, like, little tiny virtual construction workers. They're tiny virtual pneumatic drills.
So when you say "Tool 2.0" I have no idea what type of thing that refers to. When you say "Mock Tool", well, I know what a mock is, but I don't know what kind of "tool" you would "give" to a class that relates to my knowledge of what a mock is at all.
I don't know what the word "tool" means in your explanation.
-
Right; that makes no sense to me, though.
My classes don't need "tools" to do their jobs, they are tools to do a job. You don't hand them "tools" at creation time, you hand them context. Classes aren't, like, little tiny virtual construction workers. They're tiny virtual pneumatic drills.
So when you say "Tool 2.0" I have no idea what type of thing that refers to. When you say "Mock Tool", well, I know what a mock is, but I don't know what kind of "tool" you would "give" to a class that relates to my knowledge of what a mock is at all.
I don't know what the word "tool" means in your explanation.
A 'tool' here is simply some other class or function that your class uses in order to get its job done. So, to play on your pneumatic drill analogy, it's the difference between having a standard chuck on your drill that can take a wide variety of drill bits for a variety of drilling jobs (the DI case) and a bit that can't be changed without taking the drill apart, sawing off the old bit, and welding on the new bit (the hard-coded-dependency case).
-
It looks like this:
View renderATableFullOfInformation = new TableView(dataModel)public TableView(DataModel dataModel) { this.data = dataModel; this.data.fetchFromDB(); }rather than this:
public TableView() { this.data = new DataModel(); this.data.fetchFromDB(); }That way you can unit test the TableView class with a mock DataModel that doesn't hit the real database
It's really dead simple in execution, for all the big words thrown around when explaining it. Just never use "new" inside of a class other than your bootstrapping code and you're good on the DI front.
-
You don't hand them "tools" at creation time, you hand them context.
That's how I do "dependency injection" or what passes as one in my current project.
There's a global super object that holds references to all long-lived objects ("xxxManager"s and such). Each class expects a hash with the globals it depends on. In production, everything gets everything (because there's one main "app" global). In tests, I can shim what I need for the class I'm testing.
Not sure if that is DI, but it seems to serve the same purpose.
-
So basically, it's a thing I do all the fucking time already and people like to throw big words around to sound smart.
EDIT: Wait, if it's that simple, then what the fuck are the 4.87 MB of Ninject DLLs doing?
-
Put it like this: just because an idea is simple doesn't mean that giving it a name isn't very helpful, nor does it mean that everyone is doing it. (And believe me, everyone isn't doing it. :-))
Compare it to... say, a design pattern. E.g. Factory. "Hey this class creates other classes" is both a simple idea and pretty often very useful, but being able to say
FooFactoryand have everyone know exactly what it does is still useful. The GOF didn't invent their patterns, they just gave them names.
-
I've never used ninject, but my understanding is that instead of having
public void main( int[] args) { DataTable data = new DataTable(); View tableView = new View(data); //snip 30 or so lines of similar construction }you can get it down to just
public void main( int[] args) { InjectionFramework.MakeAppWork(); }or some bullshit.
The thing to keep in mind is that even though it's dead simple and feels like common fucking sense, people who have never heard of the concept (or the related concept of "seams") write crappy untestable code left and right. For them, it's a revolution.
-
I just wish the name made some goddamned sense. I've never heard of anybody saying a class was a dependency. A dependency is like a separate application or library outside of the project.
So when you say "dependency injection", my mental image is at the exact WRONG level because the fucking name is an idiot made by a moron.
Which also means that in 6-8 months, this all will be completely forgotten and next time someone mentions "dependency injection", I'll most likely be right back to start.
-
Which also means that in 6-8 months, this all will be completely forgotten and next time someone mentions "dependency injection", I'll most likely be right back to start.
Hopefully we'll get a nice rant then, because this was boring.
-
Yeah, the concept is of a class as an island and dependencies being other classes in the application rather than external dependencies to the application.
-
Also where the fuck are you people getting these metaphors from? You give a class "tools"? A class is an "island?"
WTF. This would be a fuckload easier to understand if people just spoke in plain English:
The word 'dependency', contrary to the common meaning, refers to classes your class requires instances of; injection refers to passing those required instances into the constructor instead of instantiating new ones.
WAS THAT SO FUCKING HARD!?
... is that getting better cartman82?
-
Because we don't have any idea how best to explain it to you so trying every damn metaphor in the hopes something will stick.
-
Yup - that's exactly how I came to the whole SOLID thing - (Dependency injection is a concrete example of dependency inversion - the D in SOLID) - a group of stuff I was already doing.
-
er, the "island" thing was me making an analogy to the common statement "no man is an island", that's not an industry thing. Sorry if I confused you :)
-
I just explained it in one sentence of plain fucking English about 450,000 times more clear than that bullshit about classes being little midget Mexican laborers who need to borrow a power drill.
-
Yes but not everyone can understand plain fucking English without it being wrapped up in metaphors and similes.
-
This actually reminds me of the discussion ages ago about right-handed vs. left-handed coordinate systems, and how the mnemonic of "handedness" made the topic about 50,000 times more confusing than it people would have just explained it in plain English without staring at their hands in weird contorted positions.
-
-
WTF. This would be a fuckload easier to understand if people just spoke in plain English:
>The word 'dependency', contrary to the common meaning, refers to classes your class requires instances of; injection refers to passing those required instances into the constructor instead of instantiating new ones.
WAS THAT SO FUCKING HARD!?
You're a fucking illiterate. There's nothing wrong with the usage of the word Dependency in Dependency Injection.
-
You're a fucking illiterate. There's nothing wrong with the usage of the word Dependency in Dependency Injection.
Demonstrably there is.
-
Dependency Injection is fecking awesome.
I pass in an object into something and just make sure it implements and interface ... if I change the rest of the app later on but still implement the interface everything still works.
Easier unit testing is one of the benefits as you can swap out a mocks and stubs as long as the implement the interface.
That is all there is to it.
As for complaining about terms ... we of software professionals we have our own lexicon pretty much anyway.
-
This actually reminds me of the discussion ages ago about right-handed vs. left-handed coordinate systems, and how the mnemonic of "handedness" made the topic about 50,000 times more confusing than it people would have just explained it in plain English without staring at their hands in weird contorted positions.
+Z goes away vs. +Z goes closer?
You're a fucking illiterate. There's nothing wrong with the usage of the word Dependency in Dependency Injection.
It's not immediately obvious what's meant by "dependency injection."
unit test
I keep hearing about these legendary creatures. Perhaps one day, I will witness one of them in the wild.
-
It's not immediately obvious what's meant by "dependency injection."
Probably true, but there's not any reasonable way to shorten a definition for something that complex and make it all immediately obvious. I wouldn't say it's misleading.
Demonstrably there is.
Yes, in the same way that some people won't admit to understanding the word "is."
-
Probably true, but there's not any reasonable way to shorten a definition for something that complex and make it all immediately obvious. I wouldn't say it's misleading.
It's kind of like shoe leather costs. "Inflation results in shoe leather costs. Why shoe leather costs? Because raising cows for the leather is more expensive? Do we even use leather in shoes anymore?" I much prefer another term used to describe similar pressures, because the connection is instant even to someone unaccustomed to economics jargon.
-
Demonstrably there is.
Or, possibly, demonstrably, you're unable to understand concepts other people grasp easily, and unwilling to use reason in attempting to figure them out.
-
So basically, it's a thing I do all the fucking time already and people like to throw big words around to sound smart.
A lot of software patterns are like that. Common sense, codified (and then exalted beyond all reason, but let's rant about that some other time).
@blakeyrat said:EDIT: Wait, if it's that simple, then what the fuck are the 4.87 MB of Ninject DLLs doing?
Probably trying to wire things up automatically. It's an awesome trick when it works, and gets more and more awesome as an application gets bigger.They might also be doing complicated intercepting delegates and shit like that, which can make some things much simpler. (The canonical example is handling a database transaction, which can be a complete pain in the ass to code up manually each time. Push it out to some sort of delegate and then you get to say “this is all in a transaction” with just a simple annotation. It de-fucks code ever so nicely.)
-
Or, possibly, demonstrably, you're unable to understand concepts other people grasp easily, and unwilling to use reason in attempting to figure them out.
What are other things that should confuse the shit out of blakey because they are used in different ways in IT?
- Template
- Object
I'm sure there are others. Just be aware, if you use these in a different context than @blakeyrat's default, you are being a shit.
-
Everybody is being a shit.
At all times.
-
-
Just today I decided to finally read up on those, 'coz I never used them back when I did C++.
Based on similar syntax, I was guessing they worked somewhat like C# generics. Turns out: they do! Job's a good 'un. Off to the pub!
Filed under: I love it when a plan comes together
-
Based on similar syntax, I was guessing they worked somewhat like C# generics. Turns out: they do! Job's a good 'un. Off to the pub!
Vaguely. But implemented in a much dumber way.
-
Based on similar syntax, I was guessing they worked somewhat like C# generics.
Sort of, but with a few critical differences.
For example, in C# you use types there. In C++, you use types or compile-time constants there. What's more, in C# all interesting types are reference types; in C++, you've got non-reference types too, where you can't generate any code without following the type rabbit all the way down the hole. And this all means that the C++ compiler will go away and evaluate what is effectively a (shitty) functional programming language to decide what your program is really trying to do.
To cap it all, C++ has a community of developers that think this is a wonderful idea to be used as much as possible. This is particularly true of the key core libraries: the Standard Library and (most especially) Boost.
I hate C++. There are some complete and utter fuck-ups in it that make a simple task like merely reading someone else's code a non-trivial challenge. There is much to criticise with Java ([spoiler]and perhaps also with C#, though it is possible to hide more sins there[/spoiler]) but it has the key thing that the simple reading of someone else's code is the right one. If something is complicated, it looks complicated; if something looks simple, it is simple.
-
in C++, you've got non-reference types too
Yeah, when I saw that part, my reaction was: "Can I get a 'Hell, yes!'"
I hate C++. There are some complete and utter fuck-ups in it that make a simple task like merely reading someone else's code a non-trivial challenge.
Me, I actually like C++, though I have been out of the loop for a while now (these days, I do the majority of my work in C#). I never liked it quite as much as vanilla C, but that was an elegant weapon for a more civilised age.
So, C++ is non-trivial to read and you can do yourself an injury if you're not paying attention to what you're doing... Well, that's what makes it a language for Real Men.
out of me…
