Do you use dependency injection frameworks?

That is literally a reimplementation of normal construction, proxied through injection for no good reason.

guice pays really well though

It's automated so you have to program less. Realistic example is injecting db connection object into very instance that needs it. Easier than doing it yourself and better than having globals since injection makes testing easy.

yeah but sometimes it's really annoying to build an instance of an object that needs an instance of an object that needs an instance of another object ad infinitum

Program less and configure more.

I prefer to program.

Each object can construct the objects it immediately needs. If X depends on Y and Z and constructs them as needed, and A depends on X, A only needs to construct X, which will automatically construct Y and Z. You never have to manually construct the entire dependency chain every time you want to instantiate something unless you're doing something horribly wrong.

There's different ways like auto but like a configurable registry that can create instances. Assuming the letters are types, its like registering a(b,c), b(d), c(), and d=1 then saying gimme "a" and it returns a instance created like a(b(d),c())

In my experience what you call "programming" is just an abstraction for configuration given a set of requirements.
It's not as if the projects you write are appreciably different. Always using the same databases, servers, etc.

How many of you guys actually do something other than CRUD/ETL?

I do. Tooling for automation of ops.

All I'm saying is it's a pain in the ass to construct the entire fucking chain for a series of tests when it can be done in one fucking line.

And all I'm saying is that you don't need to do any of that construction yourself if you just don't use dependency injection where it doesn't belong.

you are supposed to mock away all dependencies in unit tests user

Yeah, that's what the dependency injector does for me. I only tell it which component is under test and it fakes out the rest.

>It's incredibly simple and you absolutely don't need a framework for it.
You clearly have never had to construct a dozen different Factories and Builders passed into each other.

I use it, but I don't really understand how it works

just use the reader monad lmao

This makes it sound like dependency injection is a kludge, and that the real problem is just Java in general.

Yes. If you don't know why you'd want to, read the first few chapters of this.

Attached: 51tDWqI9pfL._SX402_BO1,204,203,200_.jpg (404x500, 29K)

>You clearly have never had to construct a dozen different Factories and Builders passed into each other.
You're right, and I'm proud of that. I don't usually shit on popular paradigms because I figure there has to be good use for them, even if I never run into them. But the shit you're describing just seems like absolute garbage, and a good indication that you just don't know the best way to structure your programs, so you're falling back to generic one-size-fits-all OOP patterns

Of course. I don't want to litter my code with singletons that may or may not be threadsafe. As well as minimizing allocation overhead by instantiating everything at boot time.

Do you niggers even code

Microsoft.Extensions.DependencyInjection is all you'll ever need from a service locator in .NET.

yes we use guice at work

>brought to you by google
nty

dependency injection is code smell

I bet that library calls back home

>Guice (pronounced 'juice')
Get fucked.

sounds like security hazard

This is fucking retarded and so bloated that I no longer wonder why modern software is shit.

ever heard of static singleton

guava is the shit though

This

that's funny because i work in a guice shop and people say the exact same thing about spring

Dunno about Guice but every IoC container I've used allowed for both singletons and to construct objects per class

The only thing that is retarded here is you.

found the googler

Instead of developing Guice, Google should have just rewritten their entire codebase in Haskell, which actually has meaningful abstractions, as opposed to the non-abstract indirection crap that is "dependency injection".

Fuck Guice.

I don't see how this is different from constructing other objects in a constructor.

I don't see how this is different from passing parameters into a constructor.

>Haskell
>meaningful abstractions
ohoho
spotted the CS101 brainlet

>I don't see how this is different from constructing other objects in a constructor.
you never worked on large code bases

I don't use dependencies

DI frameworks can be nice for reducing the boilerplate that you would have if using constructors as you describe

suppose you have a system with a bunch of domain objects, foo, bar, etc. so more than likely you'll end up with a FooDao class, a FooService, a FooValidator, a FooSanitizer, and more than likely you'll have similar classes for each of your domain objects. rather than needing to pass each of these classes for each of your domain objects into a constructor, you instead declare in your DI module the existence of your FooValidator, Sanitizer, etc. and in your e.g. FooService class, you say "DI, give me an appropriate Sanitizer", and the DI framework handles the lookup of what the appropriate class to provide is.

not just that, all your dependencies might be difficult to construct, and so are their dependencies, and so on, so on, it's nice to never worry about it and just do a single

@Inject

what do you mean by difficult to construct?

Eg: I want the validated security context of the current user, I could either inject it, or figure out how to construct all 50 classes in the dependency chain

>pronounced 'juice'

Attached: 1503092631567.png (732x633, 241K)

The point of injection, as I understand it, is that you might want X to depend on an abstract interface that can be satisfied by either A, B or C, depending on runtime configuration.
(I wish someone would be able to offer a real-world example that isn't blatantly retarded, though.)

we just gave one

What, do you mean ? Maybe I'm just a dumb Python guy, but I cannot for the life of me understand why you would need to have multiple language objects to represent your domain object. What the fuck is a FooValidator, anyway? Is there a compelling reason in Java to not just write a .validate() method?

>(I wish someone would be able to offer a real-world example that isn't blatantly retarded, though.)
Deploying stubs for external services on development machines, while the production build queries the actual services.

>Is there a compelling reason in Java to not just write a .validate() method?
sure, you could have all your domain objects implement the interface Validatable, or some such. although if to validate you need to provide some context, or make cache lookups, now you're introducing this stuff into your domain object class and writing messy spaghetti code

In java it's a way to make your code harder to read the flow of by constructing member variables of an instance by reading xml files at runtime that are embedded in the .jar file and different xml files are used depending on your config.

The same thing can be done by calling a static function to construct your member variables, but then it's less magical and confusing.

It's easier to understand the flow of code if you write code instead of using external libraries that construct your data by using runtime magic using reflection and sometimes even xml files.
Also your IDE can't help you as much when you have config files.

guice doesn't use xml

most based post in this thread

In reality it's most useful when doing unit tests on code that's calling database or some http stuff, because you can just mock those two things and inject them instead of the real implementations with little effort.

found someone who either doesn't have dev job or writes untestable code.

This user knows his shit.

>unit testing
I have yet to be convinced that it is not a waste of dev time and money.

>either doesn't have dev job or writes untestable code
Wrong on both counts.
I write microservices whenever possible. Every time I commit to any of them, our CI/CD tooling automatically redeploys the application and runs a full suite of integration and and E2E tests on an entire reproduction of our pipelines in a dev environment. I have the shortest average dev time and some of the most stable code in the company because of that setup, and a few other devs have recently started picking up my preferred methods.
I do not usually write unit tests. I have almost never found them necessary in properly architected code bases.

Every non-trivial professional software project is at some point going to expand to the point where it's impossible for any single programmer to have a complete and full understanding of the ins and outs of every procedure in the code, which means that after that point, any time you are tasked with changing some core piece of functionality you're going to have to spend 5 to 20 minutes crawling through the dependencies of the code you are trying to change to ensure your proposed change isn't going to cause anything unexpected to happen during runtime.
Properly written unit tests allows you to be a lot more reckless with your changes, since if you break something, the test will let you know exactly what part about the method you just changed and it's larger role in the system you misunderstood.
Unit tests also allow you to get new programmers up and contributing quicker since they won't have to be afraid of making breaking changes.

The problem is that 95% of all enterprise programmers are absolutely fucking trash when it comes to testing.

sometimes, unit tests are good
sometimes, they are more trouble than they're worth
whether to use them or not needs to be the decision driven by an experienced developer
not e.g. 100% code coverage mandated topdown by management removed from the actual code base

>instead of writing a tool to solve a problem, Google should have shut down and spent billions of dollars and a decade rewriting all of their working code.
This is why you aren't successful.

No, it would be the opposite. It means that if you were to change the class constructor signatures, you'd only need to do it in one place which prevents potential issues that arise when refactoring.

there is a Scala feature that sounds similar but not that retarded, dont remember the name but it basically selected parameters for construction automatically based on what is needed and already in scope, basically just removing the need to hand over everything to constructors

i wish i could understand dependency injection

Attached: hmm.jpg (768x768, 67K)

Underrated point. If you're going to automate real-ish E2E testing then yeah you wouldn't need to DI + mock unit tests. We DI at my job but almost only do E2E so it's kind of pointless. This thread is a reminder that I should do more mocked unit tests. Thanks neets.

Your future self will forget what makes some block of code work vs. break and you'll be glad there are tests as proof that your changes don't fuck everything up. But yes, your fizzbuzz doesn't need test coverage.

It's a good example of dogshit CS pedagogy because of how nobody seems to bother splitting the concept up into its parts.

Suppose you have some class that takes an instance of another class as part of its construction. Rather than being responsible for spinning up both at once DI just means some over-arching container either already has the dependency instance waiting or can go get it on your behalf. In either case you the developer just consume the interface rather than the instantiation.

Not really underrated, any testing book will tell you you're supposed to use both unit tests and E2E tests, not one or the other.
If you write a new function that builds a URI from a bunch of strings and you want to make sure you didn't forget a separator or that it handles optional values correctly, going through a full deployment/integration tests cycle when you can just assertEquals(buildURI(), "/a/b/c/d") is extremely inefficient at best.
That guy was just bragging about his perfect workflow all his colleagues are jealous of but it's probably not as good as he makes it sound like.

Why yes, a static stringbuilder utility would be a good candidate for unit test coverage. We were talking about E2E as a substitute for mocked integration calls e.g. DB, HTTP.

Imagine ClassA needs to set ClassB string property value. Inside ClassA, you can make an instance of ClassB. Then, set ClassB string property like so.

ClassA {
var classB = ClassB();
classB.string = "foo"
}

There are different types of dependency injection.
For example, using constructors or initializers

ClassA {
ClassB classB = new ClassB(string:"foo");
}

With dependency injection, an object (classB in the example) doesn't configure its own components (string property in the example).

This is the correct answer

Object oriented programming is completely retarded, yes.

>I don't see how this is different from passing parameters into a constructor.
Creating them manually like a(b(d),c()) is what dependency injection literally is, any required dependencies are passed to the object instead of the object creating them internally. That's completely manually, there completely automatically using reflection but there's issues. I like a really simple all configuration based where you have value, instance, shared-instance items that ask the parent container for its dependencies it needs. Its preference, I like that nothing can happen that isn't set and replacing a class involves 1 config file change.

Yeah, I wouldn't use Java without something Spring or Vertex anymore. Doin't use Guice though, that shit is dead.

Just read from the horse's mouth:
martinfowler.com/articles/injection.html

i'm not taking programming advice from a horse

Attached: this does it.jpg (818x444, 98K)

What the fuck is wrong with horses? Horses are kind and empathetic creatures. I bet you like dogs you fucking double nigger, fuck dogs. They're flea ridden stupid animals that would eat your stupid fat dead corpse as soon as they see an opportunity. Horses are man's true best friend, they don't complain and they're happy to pull heavy loads for us. Fuck you you fucking double nigger faggot dog lover, if you keep talking shit about horses I will fucking stomp you out with my hooves. And don't think I won't, have you ever seen a horse? They're creatures of pure mass and muscle, you think your tiny human harms can do shit to horses? WRONG, horses could fucking end your life within a second kiddo, do you know that we measure power of cars using a metric based on the POWER of HORSES (horsepower). I'm not a horse or anything but I'm not a fucking retard who would badmouth a horse, go fucking neck yourself. Horses are wonder and intelligent creature who just wanna eat grass and be friends.

I love java and the technology behind it

but god you fucking oop factory making dumb faggots with 20 interface with "dependency injection" and dumb fucking oop shit ruin the language

fuck you fuck you fFUCKCKXJA

Attached: horse pussy.gif (347x480, 110K)

Why do OOP brainlets need buzzwords for common sense? Convince me that OOP is anything more than codifying freshman-tier design principles for consumption subhuman enterpriseAdapterPattern.SingletonIQ.faggots().

That is so fucking beyond retarded and unsanitary. Dennis Ritchie just killed himself in the grave.

[spoiler] [/spoiler] [spoiler] [/spoiler] [spoiler] [/spoiler]

>Program less
>Java
It's like enterprise fags are trained to not think.

nigger

Attached: 1536106908462.png (2650x1491, 567K)

We wouldn't need any of this is everyone was smart and mindful. It's an attempt to gate bad behaviors on a scale. Even if you are intelligent mistakes will happen or you'll slip up at some point, this is especially true as your organization becomes larger and development becomes more decentralized.

I don't do drugs, thanks.

suck my pee pee

doublenigger

Attached: bad honk.gif (500x281, 912K)

triple nigger

Attached: (You)tsuba.gif (563x506, 269K)

you're the one keeping this reply chain going

Attached: 1549222945433.gif (300x310, 18K)

Show me how you can scan for an annotation in a package without a reflection framework

You cant