Your question was difficult to follow. I had to actually go through the commits in your linked PR to find out what you were talking about as the end product of the PR doesn’t actually have the word ‘klass’ anywhere. It seems this is the code you are talking about.
What you’re asking here has to do with dependency injection (DI).
klass just happens to be the variable name you’re using to achieve the dependency injection. Dependency injection often has a an overhead and, as such, is often not immediately recognizable as a benefit. The first beneficiary of DI is often your tests. For example, in the previously linked commit, you could have tested the
RequirementSeries#render method without hitting the database by injecting a class that responded to the
count method as you desired for the tests.
If you practice DI as a matter of course, you will also eventually find that wiring up objects in your system in ways you hadn’t designed from the beginning is much more simple. You reduce structural coupling and can make the system easier to change.
I don’t think that well-written, dependency-injected-code is much harder to follow than code that isn’t written in that style. It’s a matter of getting used to the style. I don’t think using
klass as the variable is helping you any, though. I would only use that as a variable when doing something generic with singleton classes. One big step you could take to improve the code would be to give
klass a meaningful name. I’m not familiar with the domain here, but something like
requirement_finder or something would be more appropriate.
To be honest, i haven’t done nearly as much DI as I would like to have in my Ruby work. There are things about Rails that makes this difficult (it’s very hard to inject into a controller, and associations don’t take kindly to DI, for instance). I will often use it in so-called service objects or in objects that wrap external API’s (which makes it simple to switch in a fake for testing). I usually do it by injecting the instance or class into the constructor or the method as you have done here (this typically remains private once instantiated), but I’ve also seen it done by having a single class variable that controls the classes of objects interfaced with.
I’d love to see DI used more in Rails. I was just recently thinking that on my next greenfield rails project I would try to write the code such that it contained no hard-coded class names wherever this is feasible to see how it felt.