Comments on Sandi Metz: SOLID Design Principles - Dependency Injection

what do rubyists think of DIP (depending on abstra...

2011-09-19T14:21:52.074-04:00

what do rubyists think of DIP (depending on abstractions, not concretions?). Does this apply to Ruby at all?

@Michael The code is formatted with CodeRay, whic...

2009-06-04T07:03:43.803-04:00

@Michael The code is formatted with CodeRay, which rocks. It requires the CodeRay gem and something like this gist.

@Erich I totally agree. Isolating the creation of a new object into a method of its own is a good compromise between injecting the class (complete separation) and creating it in the middle of a bunch of other code (complete entanglement). This is all about preserving the most future options at the lowest present cost.

@Sandi: > For non-framework code, I often still...

2009-06-02T19:21:25.790-04:00

@Sandi:
> For non-framework code, I often still explicitly create the objects that I depend on.

This is ok. NTL I learned that you should at least refactor the creation of an object into an overridable factory method. This makes it easy to intercept or replace the creation if necessary. I seldom write 'new' in the middle of a statement block anymore.

Glad to see the D of SOLID in Ruby is getting atte...

2009-06-01T16:00:22.980-04:00

Glad to see the D of SOLID in Ruby is getting attention. What plugin do you use for your code snippets? They look nice :)

Ah, Pat, the to_xml example is definitely the rub....

2009-04-15T07:31:00.000-04:00

Ah, Pat, the to_xml example is definitely the rub. It goes right to the heart of the issue: Is it good style to inject dependencies even when your current use case does not anticipate changes?

When I write code I've historically done just what they did, i.e., in the initialize methods of *my* objects I get new instances of the *other* objects I depend on. However, I keep getting burned, either because my code is hard to test or because I have an unexpected need to reuse the code with a different dependency.

I'm holding myself to two different standards. When I write framework code that I expect others to heavily reuse, I inject like mad even if I don't have a current need. In this case it feels like my obligation is to support unexpected collaborations among objects which have well defined APIs. This ability to easily make new collaborations is a design goal of the framework.

For non-framework code, I often still explicitly create the objects that I depend on. Mostly. Except when it's easier to write tests if I don't. And these dependencies lasts until I find a need for reuse and refactor the code..

As you can see, this is still of an experiment about dependency management. We'll see how it goes.

Excellent that you'll be at GoRuCo. I'm up for a face-to-face chat!

I love "free" dependency injection. When you're d...

2009-04-12T13:10:00.000-04:00

I love "free" dependency injection. When you're dealing with old crap
code, you can break dependencies to make it more testable, but
maintain the same API by using default args as you've shown. This
makes your code more testable without breaking existing clients. Huge
win.

As for your to_xml example, I can go both ways on that. First there's
the idea that you shouldn't build flexibility in that you don't
need...the lack of a configurable serializer is not necessarily an
oversight on their part. You should refactor that flexibility in when
you need it. If you did that though, then wouldn't the first
iteration of every project be one big ol imperative script, with no
organization whatsoever, right?

There's a common theme running through the Rails code base, and that
theme is that it's not extensible using standard OOP techniques. They
have hook points for high-level behavior, but if you want to change
stuff under the hood then you're in for a lot of alias_method_pain.

I was about to say that the D in SOLID seems to be neglected in our
world...but I'd say that it's SOLID in general that is. Nice to see
you getting the word out! Also I'm attending GoRuCo, can't wait to
hang out again!!

Hi Sandi,

Great writeup! Nice simplificatio...

2009-03-28T12:51:00.000-04:00

Hi Sandi,

Great writeup! Nice simplification of dependency injection. So many people think of frameworks like Spring and others from the Java world every time someone talks about dependency injection.

Mark Menard

PS: We met at Obie Con in Boston in November.