4
Axel406
3y

Dependency injection is the most useless piece of crap ever invented. Convention over configuration my ass.
It simplifies nothing a good architecture and pattern can't solve. It's just the current trend but it's the hugest pain in the ass I've ever experienced. It just adds complexity to the project.
I think it's just a thing for masochists and lazy devs, but then why not sticking a huge dido up your ass it's the same fucking thing.

Comments
  • 9
    Sure, let me just use 10321423149021 fucking factory classes instead, like a true Java developer.
  • 2
    Are you talking about a DI container or dependency injection in general?

    And what do you think of dependency inversion?
  • 14
    Then you have not understood the pattern and possibly are not doing unit testing.

    I have been using DI for a decade and its really helpful. And it was not new when I started so a long lasting trend it is ;)

    But I have also seen examples of bad DI.

    Almost a patterns can look bad if used in the wrong way but to claim something useless you need to state that it is your own opinion or be a world renowned expert.

    The fact that it is so very wildly used proves it to be solving some problems and doing a better job than at least some other patterns or people would not use it so extensively.

    There are probably patterns that at least for some cases is better but almost all have some drawback.
  • 8
    Sure, if you have like 5 classes i your app.

    Try building a 1M+ lignes of code app and change a contructor without DI. You'll need to do like 100 changes in code.

    DI does it for you.

    It also manages the lifecycle of object. Want a nerw instance everytime ? easy.
    Want an instance per web request ? change 1 ligne of code

    Want a singleton ?(personaly I consider singletons as ani patern, but whatever) you can.

    DI is one of the BEST things in dev
  • 1
    What the others said about DI.

    Also stick a huge Dido up your ass, interesting!
  • 0
    @NoToJavaScript thanks, I just started reading about it today while learning spring. The more justification the better lol
  • 0
    @nibor who’s that woman in your photo?
  • 0
    @d-fanelli Well if you need "justificastion" you already missed the point :) GL !
  • 1
    DI adding complexity is a weird one. If I were to remove DI from my projects I don't even know where I'd start. I would need dozens of boilerplate helper methods and a bunch of "when X, remember to-" tidbits in the readme.
  • 0
    @NoToJavaScript your comment was that extra nudge I needed to get it. It allows you to set which implementing (of an interface) class is to be used by classes that have objects of those implementing classes as fields simply by making a few changes to a config file or a context class. It avoids having to change which constructor is called throughout the codebase. Its probably one of the most important things to learn when learning spring (I’m a little drunk so my explanation might be lacking lol)
  • 1
    @d-fanelli the singer Dido.

    @Axel406 not only do you seem to not understand the DI pattern, you also don't seem to understand devrant tagging! The devrant tag is for rants about the platform. This should have been in the rant category.
  • 1
    There's so much wrong in your post.
    I second what @nibor, @Voxera and @NoToJavaScript said.

    If you have a small app with a negligible amount of local dependencies then sure, you may not need DI even on tests but if you're dealing with a big code base where classes/components use numerous others, then you're going to have a tough time (unit/integration) testing them without DI.
Add Comment