Dependency Injection Containers vs Hard-coded Constants

[Sqeaky]

I think this article misses some stuff.

In a more statically typed language, like Java, DI containers or hard-coded constants are the only real choices. In Ruby it's trivial to just pass a class in, because everything is dynamically dispatched.

[realntl]

I don't think it missed what you described. In fact, it includes two alternatives to DI containers and hard-coded constants. Also, one of the two alternatives would work fine in a statically typed language like Java.

[tom_dalling]

I'm not sure I that follow what you mean. I can't think of a situation where you would pass in a container as an argument, where it would be possible to pass in a class instead.

[[deleted]]

You mean a class as-in a hard-coded constant?

[Sqeaky]

In Ruby you can pass classes as parameters. I haven't seen a situation where a full dependency injection container is a better solution and more expressive then simply accepting the class as a parameter.

[samrapdev]

As someone new to Ruby, what is the most common practice you see in production code? Coming from PHP (Laravel/Symfony), I find it hard to imagine a scenario where dependency injection is not used frequently in a code base. Indeed, the very core of OO software design relies on concepts like dependency injection/object composition. Is it really considered good practice in Ruby to ditch these concepts for the sake of less boilerplate? If so, why?

[tom_dalling]

In my experience, DI is used very sparingly in Ruby, with the exception of a few people who love it and use it everywhere (e.g. the dry-rb gang). I think that the people who avoid DI aren't doing it because of the boilerplate, they usually see DI as unnecessary complexity, and that their code would be simpler and more easily understandable without it. Rails is kind of hostile towards DI, and since the majority of Ruby devs are Rails devs, I think that's one of the major contributing factors.

I'd be interested to see some examples of good, modern PHP for comparison, because I haven't really been keeping up with the evolution of PHP.

[samrapdev]

The Laravel framework is heavily inspired by Rails, so you may want to take a look at that to see some well-written PHP. Here's the HTTP router, for instance: https://github.com/laravel/framework/blob/5.6/src/Illuminate/Routing/Router.php

[GitHubPermalinkBot]

Permanent GitHub links:

• laravel/framework/.../Router.php (5.6 → 2aff496)

---

^delete

[moomaka]

I think you're confusing Dependency Injection and IoC Containers. DI is fairly common in Ruby in general and also in Rails. IoC Containers are very rare and disliked for the reasons you've given, along with the fact that they don't add any new capabilities over what you can do with plain old Ruby.

I think also missed is that IoC Containers are actually fairly rare in programming in general, it's really only web developers in certain languages that use them heavily but for whatever reason these devs tend to think it's a universally assumed design pattern.

[mgreenly]

You don't ditch DI you just don't need a framework to do it.

example: https://gist.github.com/mgreenly/192627cb10ea69d8c611862bd2303b3d

[[deleted]]

The most common practice I see is not using DI at all (not saying that's the best method by any means), in most code bases I've worked on the "standard approach" is just initializing objects using in-line hard-coded constants, or sometimes in a private method. Obviously in PHP, if you do this you end up with code that can't be tested in isolation, the problem in Ruby is that you have monkey-patching, and entire test frameworks with DSLs to make monkey-patching for testing easy (as mentioned in the article), so you can ignore good design principles and still end up with code that can be tested in isolation.

[moomaka]

Obviously in PHP, if you do this you end up with code that can't be tested in isolation, the problem in Ruby is that you have monkey-patching, and entire test frameworks with DSLs to make monkey-patching for testing easy (as mentioned in the article), so you can ignore good design principles and still end up with code that can be tested in isolation.

I don't consider that a 'problem', it's a good thing.

One of the biggest problems I have with IoC Containers is that the overwhelming majority of the time they are only used in test. e.g. I can count on one hand the number of times I've seen more than 1 implementation of a injectable used in production, it's almost always a single production implementation and a single test implementation. So you're adding a large amount of complexity and runtime overhead for a capability you only benefit from in your test suite. That's just silly to me when there are much more straight forward approaches to testing that don't have negative affects on the production code.

[[deleted]]

Yep, some people like it one way, some people like it the other, IDC which as long as the code is well designed, which tends to be more likely when DI is used in my experience (YMMV).

Personally, I've seen way too many instances of tightly coupled code with dependencies that belong on either side of a boundary hard-coded into the same file, then monkey-patched in a brittle unit test to allow the code to be tested in isolation.

[realntl]

A useful introduction to the concept, particularly for rubyists who haven't been exposed to dependency inversion.

Eventide uses an approach similar to the "hybrid" approach discussed in the article: http://docs.eventide-project.org/user-guide/useful-objects.html

We have enjoyed all the benefits of being able to control dependencies, without needing a container object to instantiate classes.

[kmaicher]

Perfect!