Filler

(Caveat: I have not seen The Hobbit in any form, I’m just reporting based on similar experiences)

Chapter I: The Story So Far

A lot of people over the years have touted the advantages of a faster frame-rate. In games, frame-rate has almost become something of a status symbol – games boasting a high frame-rate get a special place in gamers’ hearts, even if the game is no good. Gamers with the system powerful enough to achieve high frame-rates are demi-gods to whom us lesser nerds must bow down.

But many of us, myself included, have felt that this whole discussion is a bit… absurd. Let’s face it, the human eye is okay with 24 frames per second. If it wasn’t, movies wouldn’t have survived as they have, and at that frame-rate. Beyond that, some people feel the picture gets more fluid or realistic or whatever, but there’s always been debates about the value of high frame-rates. Continue reading “The Hobbit: Too Real?”

I pointed out in my last post the idiot trying to improve dependency injection by reinventing it. During my rip on his ignorance, I pointed out a lot about what was wrong and mentioned a few times that I didn’t like his approach, but I didn’t provide anything better for his specific situation. I also mentioned that a service class might be a good idea… but again, I didn’t even hint at what that would look like.

So how would I solve his problem with true DI? Well, a naive approach would simply let the caller decide what class or object to use for pulling the data and parsing it:

# lib/testing.rb or whatever
module Testing
  def self.foo(klass)
    content = klass.get "http://mygreatservice.example.com/person/1.json"
    JSON.parse(content)
  end
end

# Normal use:
Testing.foo(HTTP)

# In a test:
class FakeHTTP
  def self.get(uri)
    return '{"id":1,"name":"matz"}'
  end
end

Testing.foo(FakeHTTP)

We can immediately see some benefits here over his “Injector” bullshit. For starters, there’s no dependency on HTTP at all. We just depend on some object that responds to get and returns a hash. In a truly simple case, this is a pretty good example of DI to decouple a minor dependency.

But let’s assume his Testing module is more complex, and Testing.foo does more work. In that case, we can do far better! The naive approach requires that our DI classes return a string that can be interpreted as JSON. The logic to get data and parse data is very coupled to the Testing module, which might be a problem in itself. So here’s what I’d recommend for refactoring:

# lib/service.rb
class DataProcessor
  def initialize(args = {})
    @url = args[:url]
  end

  def data_hash
    content = HTTP.get @url
    JSON.parse(content)
  end
end

# lib/testing.rb
module Testing
  def self.foo(service)
    self.do_something_with(service.data_hash)
    self.do_other_stuff
  end
end

# Normal use:
Testing.foo(DataProcessor.new(:url => "http://mygreatservice.example.com/person/1.json"))

This looks kind of awkward at first glance, and I could certainly be persuaded to change class and/or method names in a real-world scenario, but what I’m aiming for gives us a truly isolated data service that can be injected into the Testing module.

Remember, I’m assuming that the Testing module is bigger and does more stuff, hence my dummy function calls.

So now we have a central class to process data. It pulls data from an external service and parses it as JSON, returning a Ruby hash that gives us something that’s important for the rest of the module, and probably other parts of the application. Having a class for that data gathering means we can keep the “give me compatible data from some service” logic separate from whatever else this weird Testing module does.

We’re also keeping the hard-coded URL out of the service as well as the module, allowing us to configure that from whatever source we need. If we’re truly certain that the URL should be hard-coded, it’s easy enough to make that live in the service, I’m just showing that we don’t need any of the system to rely on higher-level knowledge of configurable elements.

This approach gives us some significant benefits:

• We have a general-purpose json-service-to-hash class which may be useful elsewhere in the application
• We can very easily inject something that reads from a file instead of pulling from a service
  • We can do the same thing with other endpoints, too – databases, console input, etc. As long as the service class returns a simple hash from its data_hash method, the Testing module doesn’t care HOW the data got there, just that it got data
• For creating unit tests, we can stub DataProcessor or build a test-specific service class
  • Usually stubbing is easier, but we have the flexibility if we need it

Hopefully this explains DI as well as the value of service classes a little bit. And hopefully the original author of the “Interceptor Injection” pattern reads it and realizes he’s way too inexperienced to be writing about programming on the web.