Dependency Injection is dangerous for your career
stackoverflow.com
Dependency Injection is dangerous for your career
1–10 of 35 posts
Re: Dependency Injection is dangerous for your career
#2Hilarious. :) Some of the other answers are worth reading, too. Specifically, there is a really good one a little lower that is worth reading:
http://stackoverflow.com/questions/2407540/what-are-the-down...
> The same basic problem you often get with object oriented programming, style rules and just about everything else. It's possible - very common, in fact - to do too much abstraction, and to add too much indirection, and to generally apply good techniques excessively and in the wrong places...[answer continues]
Re: Dependency Injection is dangerous for your career
#3True. But what's even worse for your career is when you learn programming languages that don't need DI frameworks because that kind of clean separation is baked in (like Python) but then most jobs out there are Java :-(
Re: Dependency Injection is dangerous for your career
#4True. But what's even worse for your career is when you learn programming languages that don't need DI frameworks because that kind of clean separation is baked in (like Python) but then most jobs out there are Java :-(
I'll admit I've never done Java programming, but (so far as I understand the term) dependency injection is something I use a lot when writing Python code. For example, if I'm writing a method to transfer a file over a particular kind of connection, I'll make the connection object a parameter rather than have the method set up the connection itself. If I'm writing a class, I might make the connection object a parameter to the constructor, or just construct it in a helper method that I can override for testing purposes.
Am I missing some magic goo that makes Python not require DI, or do I just not understand what Java programmers mean by DI?
Re: Dependency Injection is dangerous for your career
#5True. But what's even worse for your career is when you learn programming languages that don't need DI frameworks because that kind of clean separation is baked in (like Python) but then most jobs out there are Java :-(
I'll admit I've never done Java programming, but (so far as I understand the term) dependency injection is something I use a lot when writing Python code. For example, if I'm writing a method to transfer a file over a particular kind of connection, I'll make the connection object a parameter rather than have the method set up the connection itself. If I'm writing a class, I might make the connection object a paramete…
[deleted]
Re: Dependency Injection is dangerous for your career
#6DI is generally used to solve one of three problems that are pretty much unique to Java:
Passing a function
Decoupling initialization from memory allocation (eg. making constructors work) (This problem is also shared by C# before 3.0 but you can kind of get around it by passing a function that does the initialization, or using an anonymous constructor in 3.0 and up)
Avoiding the FactoryFactoryFactory pattern where it's all factories all the way down which is a pattern designed to get around the constructor anti-pattern. Because constructors are somehow special and not just a function that returns a specific data-type. So in C# you'll wrap a constructor in a function so it can be passed, and in Java you'll use DI. (eg. Func s = () => new string())
DI is primarily a euphemism for programming in XML or another language that sucks less than Java. Primarily it's a euphemism designed to assage the egos of Java programmers who don't want to admit you can't solve problems elegantly in Java so they move their code to other languages that interact with Java to pretend Java solves more problems than it creates.
Re: Dependency Injection is dangerous for your career
#7Thats probably one of the funniest stack overflow threads I have read.
Re: Dependency Injection is dangerous for your career
#8DI is generally used to solve one of three problems that are pretty much unique to Java: Passing a function Decoupling initialization from memory allocation (eg. making constructors work) (This problem is also shared by C# before 3.0 but you can kind of get around it by passing a function that does the initialization, or using an anonymous constructor in 3.0 and up) Avoiding the FactoryFactoryFactory pattern where it…
DI is generally used to solve one of two problems that are pretty much unique to Java:
Passing a function
If you will pardon my English: What a load of bullshit.
I'm sure it can be used for that as well (i.e. in implementing the delegation pattern, due to lack of delegates and first class functions), but saying that is what it all that is good for simply makes you look inexperienced.
For any system with a reasonable complexity you will find yourself wanting to separate your code into modules. It might be that you want to thoroughly implement SOC (seperation of concerns), it might be that you want your code to be more flexible (i.e. be able to replace a file-store with a db-store later) or simply that you realize that your system is so big, that you need to be able to work with components separately to be able to properly test your modules.
Decoupling initialization from memory allocation
First you criticise Java, then you bring up a point which (usually) is not a very big concern in garbage-collected languages.
Maybe you mean "controlling initialization" which is crucial for testable code, but given how your first point is completely off base I'm not really sure I would give you the benefit of the doubt.
DI is primarily a euphemism for programming in XML
You can implement DI without any XML. And no, for reference, I don't do Java.
Re: Dependency Injection is dangerous for your career
#9DI is generally used to solve one of three problems that are pretty much unique to Java: Passing a function Decoupling initialization from memory allocation (eg. making constructors work) (This problem is also shared by C# before 3.0 but you can kind of get around it by passing a function that does the initialization, or using an anonymous constructor in 3.0 and up) Avoiding the FactoryFactoryFactory pattern where it…
DI is generally used to solve one of two problems that are pretty much unique to Java: Passing a function If you will pardon my English: What a load of bullshit. I'm sure it can be used for that as well (i.e. in implementing the delegation pattern, due to lack of delegates and first class functions), but saying that is what it all that is good for simply makes you look inexperienced. For any system with a reasonable…
I know you can implement it with out XML, I do DI all day long with functions. I just don't call it DI, I call it passing functions. When people talk about DI they're generally talking about using a DI framework. My point is that the concept is trivial enough to implement in the language itself and doesn't require a framework to help 'manage' it.
What problems can be solved with DI that can't be solved by passing a function? Or 'controlling initialization'
Allocation issues are present in GC languages because of the overhead of GC when you could just reinitialize an existing piece of memory. (You also get to keep your L1/L2 caches hot by not initializing new memory when old will do) Allocation has non-trivial costs. This is why using the methods that allow you to pass a byte[] buffer are often more efficient than those that allocate their own buffer. And we're not even getting into the fragmentation that can occur when you're rapidly allocating memory and some of that memory is locked by the OS so it can't be collected.
How is it that DI frameworks are necessary for large code bases yet most operating systems don't have DI frameworks?
When most people writing OO code have a problem, they think 'I know I'll use a DI Framework', now they have two problems.
Re: Dependency Injection is dangerous for your career
#10True. But what's even worse for your career is when you learn programming languages that don't need DI frameworks because that kind of clean separation is baked in (like Python) but then most jobs out there are Java :-(
I'll admit I've never done Java programming, but (so far as I understand the term) dependency injection is something I use a lot when writing Python code. For example, if I'm writing a method to transfer a file over a particular kind of connection, I'll make the connection object a parameter rather than have the method set up the connection itself. If I'm writing a class, I might make the connection object a paramete…
Am I missing some magic goo that makes Python not require DI, or do I just not understand what Java programmers mean by DI?
Sometimes it's easier to assume Python-developers are blind to architectural problems and common solutions to those.
Not saying Python isn't used in large, complex problems or that all Python-code is spaghettti-code, but there are a lot of wannabe cool Python-hackers ("ninjas") out there and part of being "cool" in that sense is disregarding everything which looks even slightly like design patterns.
In those circles "Design patterns" means enterprisey, verbose code with FactoryFactories and not guidelines for how to structure your code to solve problems which have been solved before you.