Hacker News Reader

Comment by r00k | Hacker News Reader

So we set about to re-write Querulous using my favorite modularity techniques: Dependency Injection, Factories, and Decorators. In other words, everything you hate about Java.

Hey there Mr. Strawman.

I write mostly Ruby, and I use dependency injection, factories, and decorators liberally. There's nothing in Ruby that makes these any harder than they are in Java (in fact, I'd argue they're easier.)

Two years ago, when this piece was written, the author had more of a point: some people rejected anything that reminded them of Java out of hand, including design patterns.

These days, I'd argue that interest in classic OO design ideas is experiencing a massive resurgence in the Ruby world.

View on HN

RE: "classic OO design ideas experiencing a massive resurgence"

I don't know about that. I see a whole lot of functional paradigm chatter these days. That wasn't true 5 years ago as I recall.

Then again, I suppose it depends on what color your glasses are: If you're a classic OO devotee you see most of the techniques being put forth as classic OO, and if you know a bit about FP you see it all as the stuff that FP has always been made of, the stuff that OO gurus who cut their teeth on FORTRAN neglected to mention came from FORTRAN.

Yea, people see what they are interested in. At the same time, I am really stoked by what I am learning as the Ruby Community "remembers" classic OO design.

Here are a few recent examples hinting that the Ruby community is moving on from "Fat models and skinny controllers" to the beginnings of really teaching each other about classic OO...

http://www.confreaks.com/videos/1115-gogaruco2012-go-ahead-m...

http://www.confreaks.com/videos/1233-aloharuby2012-refactori...

http://www.confreaks.com/videos/1112-gogaruco2012-sugar-free...

http://www.confreaks.com/videos/1133-scrc2012-thinking-in-ob...

Being a former fortran rogrammer (fortran II at first) I am intrigued what concepts in the oo world came from fortran?

WatFIV is so long ago that I can't even make a illuminating joke about this. Maybe he meant Smalltalk.

Well, watfiv was kind after my fortran career, so I cant clarify from there.

Why would you ever use a "factory" in Ruby?

I'm less certain that DI is "wrong" in Ruby, although it's definitely unidiomatic.

I use a factory for the same things you use them for: to build objects.

For example, I use factories to create test objects that are complicated to set up (using a gem named factory_girl, actually).

Also, in Ruby, every class is a factory for its own instances. If I define a class called User, I can assign the class object User to a variable:

factory = User

Then I can call

factory.new

and receive a new User instance.

As for DI, it's not wrong, nor is it unidiomatic. Plenty of folks in the community use it, and often.

A commenter elsewhere in this thread says that DI is unnecessary in Ruby because you can just reopen or redefine a class whenever you want. That's technically true, but isn't a good practice, as it can lead to some rather rapid foot shootery.

If you want to swap in different-behaving dependencies, DI is a straightforward choice. Reopening an existing class and mangling it can cause very confusing behavior, and is generally avoided by experienced Rubyists.

I thought you perhaps meant something more than class objects.

Regarding DI: Jamis Buck infamously used DI for net/ssh and posted that he regretted doing so, because DI felt out of place in Ruby. I'm not spoiling for an argument about its virtues.

Regarding "experienced Rubyists" and reopening classes, I think you should have a look at activesupport/core_ext.

I really don't understand why people think DI is wrong in Ruby. Decoupling is universally considered a good thing in every programming language. DI is a way to achieve decoupling. What about Ruby makes this unidiomatic?

You can redefine any class in Ruby, so you never need to do dependency injection. If you want to test class A independent of class B, you redefine class B in your test. In that sense , dependency injection is a feature built in to Ruby, which is why no Ruby programmer talks about it.

It's been said that every programming pattern is a programming language design flaw. This is evidence in favor of that.

For me, dependency injection is not only a matter of testing, it's a question of clarity. Show me, right in the constructor, what your class depends on.

Dependency Injection is a way to achieve Inversion of Control - meaning the consuming modules aren't concerned with the implementation or instantiation of their dependencies. Dynamic languages have less of a need for Dependency Injection than statically typed languages, but things like instance lifecycle management and policy injection are still very much relevant for good modular design.

The point is, inverting control doesn't need a three letter acronym in Ruby, it is built into the language. You get those things automatically. No javascript programmer ever talked about singletons, and no Ruby programmer ever built an IoC container, because they are not needed. It's a mistake to think these are fundamental elements to programming, they are byproducts of particular languages.

Actually there is a framework: https://github.com/JoshCheek/deject

Have't tested it yet but it makes a lot of sense.

Redefining a class isn't dependency injection it's a hack to get the compiler to stop complaining. It works but it's very unclear to the person reading the program that a class your code depends on was actually redefined somewhere else.

For testing purposes placing this mock class somewhere at the start of your code is clear but only ever practical in that scenario.

I can also imagine that some programmers might not even think of the possibility that some code they depend on was overridden somewhere else.

In real maintainable code where you want to swap out behaviours it's nice if there was a special way of defining your dependencies. This is the same for all languages.

Deject offers a way so you don't have to fiddle with constructors but instead you have handles in your classes that you can override with different behavior if needed.

TL;DR: Yes, Ruby is powerful and you technically don't need IoC containers. But to make it maintainable for everyone it's a good idea to do so anyway.

Even if you don't give it a name, you are still doing it.

Yes, Like IntegerFloatAdding. If a programming language needs a pattern for adding an integer and a float, well, you have to call this pattern something. Until such a language is made, we can forget about "IntegerFloatAdding Pattern".

Yes, because it's a great idea to go globally changing things that are used across the virtual machine by the code of many more people than just you.

I must have blinked and missed whatever happened that made everyone think global variables are now all the rage.

...feel free to let me know why it's a good idea. Reflexive downvotes don't let me understand the voter's point of view.

That sounds like an awful idea.

> although it's definitely unidiomatic.

Most Ruby books I've read that have been published in the past couple of years seem to disagree.

It's still happening. I'm constantly seeing ignorant comments about AbstractSingletonProxyFactoryBean!

Here's a perspective that is not from ignorance: http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...

Reply on news.ycombinator.com