DEV Community: Daniel Goh

Decorating Service Objects - FunctionalObject

Daniel Goh — Fri, 30 Jul 2021 04:11:53 +0000

A common pattern used in Ruby programs are Service Objects. They help enforce the Single-responsibility Principle throughout the app, which in turn makes the program easier to test, debug and reason about.

  result = CheckoutService.new(item: item, user: user).call
  if result.successful?
    ...

At my workplace, we use service objects extensively in our codebase. One modification we made to them was to shorten the code it takes to invoke the service. All our service objects are invoked like this:

  result = CheckoutService.(item: item, user: user)
  if result.successful?
    ...

It's a minor code shortening, but it also enforces a single interface to invoke the class within the entire program. It's like we are saying "Only invoke services with the #call method".

Implementation

Implementing this pattern is pretty straightforward.

First, we define a base class for all our Service Object's.

  class ApplicationService
    def self.call(...)
      new(...).()
    end

    def call
      raise "Not Implemented"
    end
  end

Here, we do two things.

  def self.call(...)
    new(...).()
  end

One, we define a class method self#call. It doesn't care what arguments it receives (see this footnote if you're wondering what (...) does), it just forwards them to new() and then immediately invokes #call by chaining .() behind it.

  def call
    raise "Not Implemented"
  end

Two, we enforce that all subclasses define #call- we raise an error if it isn't implemented.

Then we make all our service classes inherit from our base class.

class FooService < ApplicationService
  def initialize(name: )
    @name = name
  end

  def call
    "Hello #{@name}"
  end
end

That's it. All classes that inherit from ApplicationService needs to adhere to the #call class signature, and can be invoked with the shorter method.

FooService.(name: "Dan")
=> "Hello Dan"

One step further

As you can see, this pattern can be applied to any Ruby class. In the future, you might have other classes in your program that you also want to invoke with this shorthand method. In that case, you can implement it as a mixin.

module FunctionalObject
  module ClassMethods
    def call(...)
      new(...).()
    end
  end

  def self.included(klass)
    klass.extend(ClassMethods)
  end

  def call
    raise NotImplementedError
  end
end

Now any class that wants to behave similarly can just include the mixin, like so.

class ApplicationService
  includes FunctionalObject
end

Footnotes

Method Forwarding Operator

Since Ruby 2.7, the (...) operator can be used to forward all arguments from a forwarding method to a concrete method.

  def forwarding_method(...)
    concrete_method(...)
  end

See the official docs for more info.

Deconstructing Block Arguments In Ruby

Daniel Goh — Thu, 29 Jul 2021 14:01:12 +0000

We usually use block arguments like so:

[[1, 2, 3], [4, 5, 6]].map { |arr| arr[0] }
=> [1, 4]

We also know that we can deconstruct the arguments using the splat operator, like so:

[[1, 2, 3], [4, 5, 6]].map { |first, *rest| rest }
=> [[2, 3], [5, 6]]

But what I recently found it is that we can also deconstruct block arguments like so:

[[1, 2, 3], [4, 5, 6]].map { |first, second, third| first }
=> [1, 4]

We can also group arguments up with parentheses to deconstruct them, like so:

{foo: "bar", bim: "baz"}.each_with_object({}) { |(key, val), memo| memo[key] = [key, val] }
=> {:foo=>[:foo, "bar"], :bim=>[:bim, "baz"]}

Inspecting Ruby Method Params

Daniel Goh — Thu, 29 Jul 2021 14:00:15 +0000

At work, my colleague created a gem that is used by the company's codebase. It's an extension to Sidekiq- it inspects the Ruby background job classes we have and adds a page on Sidekiq's dashboard. This allows us to schedule whatever jobs we have "adhoc".

Therefore, it needs to know what arguments each job accepts, and accept parameters that are input via the web and feed them properly when calling the job classes.

In Ruby, this means, it needs to be able to discern between positional arguments and keyword arguments. I dug through the gem a little to open a PR to modify it, and just wanted to share how Ruby allows you to introspect methods.

In ruby, a class method can stand on it's own as an object like so

class Foo
  def bar(a1, a2, b1:, b2: true);end
end

meth = Foo.instance_method(:bar)
=> #<UnboundMethod: Foo#bar(a1, a2, b1:, b2: ...) (irb):12>

The method object has a few cool instance methods you can call. One of them is #parameters. It will spit out the types of methods it receives in detail.

meth.parameters
=> [[:req, :a1], [:req, :a2], [:keyreq, :b1], [:key, :b2]]

meth.parameters
  .group_by { |type, _| type }
  .each_with_object({}) do |(type, params), acc|
    acc[type] = params.map(&:last)
  end
=> {:req=>[:a1, :a2], :keyreq=>[:b1], :key=>[:b2]}

Here's the official docs that contains a full list of other instance methods that can be called on the Method object.

And here is the PR that I opened in my colleague's gem, for reference.