Benefits of Having a Call Method for Your Ruby Object

Exploiting Ruby’s Object Model to Ease Collaboration

One of the common patterns I use in my day-to-day Ruby 📖 coding is to define a module or level call method. I like to establish these call methods as crisp interfaces between different concerns.

Dependency Injection with Objects That Respond to Call

In the following example I’ve constructed a “Package” class that has a deliver! method. Let’s take a look:

module Handler
    # Complicated logic

module Notifier
    # Complicated logic

class Package
  def initialize(origin:, destination:, notifier: Notifier, handler: Handler)
    @origin = origin
    @destination = destination
    @handler = handler
    @notifier = notifier
  attr_reader :origin, :destination, :handler, :notifier

  def deliver!(with_notification: true) self) if with_notification self)

If I want to test the deliver! method I have a few scenarios to consider:

  • I’m not sending a notification
  • I’m sending a notification and it raises an exception
  • I’m sending a notification and it succeeds

And let’s assume that both and are very expensive to run in test. Without stubbing or mocking, I could write the following test:

def test_assert_not_sending_notification
  # By having the notifier `raise`, we'll know if it was called.
  notifier = ->(package:) { raise }
  handler = ->(package:) { :handled }
  package =
    origin: :here,
    destination: :there,
    notifier: notifier,
    handler: handle

  assert(package.deliver!(with_notification: false) == :handled)

Dependency Injection Using a Collaborating Object’s Method as a Lambda

There are some interesting pathways we can now go down. First, what if we really don’t like the .call method naming convention?

module PlanetExpress
  def self.deliver(package:)
    # Navigates multiple hurdles to renew delivery licenses

We could create an alias of PlanetExpress.deliver but we could also do a little bit of Ruby magic:
  origin: :here,
  destination: :there,
  handler: PlanetExpress.method(:deliver)

The Object.method method returns a Method object, which responds to call. This allows us to avoid modifying the PlanetExpress module, while still enjoying the flexibility of a call based interface.

This is perhaps even more relevant when I think about interfacing with ActiveRecord. Are there cases where I want to have found a record and process it? Maybe the creation of that record is expensive. Let’s short-circuit that.

class User < ActiveRecord::Base

# An async worker that must receive an ID, not the full object.
class CongratulatorWorker
  def initialize(user_id:, user_finder: User.method(:find))
    @user =

  def send_congratulations!
    # All kinds of weird things with lots of conditionals

With the above, I can now setup the following in test:

def test_send_congratulations!
  user = "")
  finder = ->(user_id) { user }
  worker = "1", user_finder: finder)


In the above scenario, I’d be scratching my head if I saw a method declared in the User class. But in the CongratulatorWorker I would have a bit more of a chance of reasoning what was going on.

Using a Method Object as a Block

This example steers in a different direction, but highlights the utility of the convention of having a call method.

module ShoutOut
  def self.say_it(name)
    puts "#{name} is here"

["huey", "duey", "louie"].each(&ShoutOut.method(:say_it))

I was hoping that I could define call on ShoutOut and use that as the block (e.g. .each(&ShoutOut)). But that did not work.


This degree of dynamism is one aspect I love about Ruby. And it’s not unique to Ruby; I do this in Emacs-Lisp.

Early in learning Ruby, I stumbled upon a few statements that inform Ruby:

  • Everything’s an Object
  • A Class is an Object and an Object is a Class

And even the methods on an Object are themselves Objects. What’s nice about that is these objects have shape and form; you can see that in “detaching” the method and passing it around.