Developers writing code in object-oriented languages like Ruby and JavaScript have a complicated relationship with inheritance. I have seen opinions stating that class inheritance is absolutely evil and should be avoided in all circumstances, and those who favor composition over inheritance, but don’t discount class inheritance entirely.

Those that are against class inheritance entirely often favor composing classes with modules to add behavior. The funny thing here is that including modules functions pretty much exactly the same as class inheritance. If a method is not defined in the class, Ruby looks up the inheritance tree, starting with the modules included.

The favor for composition comes from the fact that composing classes with modules is more flexible than what a class hierarchy offers and classes can essentially achieve multiple inheritance through module inclusion.

I decided to take the idea to its extreme recently in a project at work. After students enroll in courses at Bloc, they are taken through an onboarding workflow where they create a profile, select their mentor, create a schedule of appointments, etc. We created a neat class called OnboardWorkflow that defined a series of determined steps so that students would go through onboarding in the order we wanted them to.

Rails developers are familiar with the maxim “fat models, skinny controllers”. If logic starts creeping into our controllers, most developers seem content to push that logic into a model. But obese models can make for painful development. At Bloc, we’ve reached the point where this has become painful enough that I decided something needed to be done about it. After reading through Jim Gay’s fantastic Clean Ruby, I identified many areas in which our application could benefit from the DCI (data, context, interaction) design pattern.

DCI, according to that wikipedia link above, “separates the domain model (data) from use cases (context) and Roles that objects play (interaction)”. In Clean Ruby, Jim Gay illustrates this concept with transferring money between two accounts. The domain model is an account, which takes on the role of a transferrer of money from itself to another account, in the context of transferring money.

The situation I came across in the Bloc application involved populating a progress bar with data related to a student’s enrollment. This used to be fairly straightforward, but after introducing our Track products, in which students can take a track of two courses, it became a little more complicated.

This post first appeared on the Bloc blog in January 2015

As code bases grow, the need to refactor grows with it. A couple weeks ago, I saw an opportunity to refactor Bloc’s scheduled emails, which we activate in a Rakefile.

The Rakefile looked something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

task :send_greeting_email => :environment do
  Enrollment.starting_in_the_next_two_weeks.each do |enrollment|

    EnrollmentMailer.program_coordinator_greeting(enrollment).deliver
  end
end

task :send_get_started_emails => :environment do
  starting_enrollments = Enrollment.where('course_start_date > ? AND course_start_date < ?', Time.now, Time.now).where(sent_get_started_email: false)

  starting_enrollments.each do |enrollment|
    EnrollmentMailer.get_started(enrollment).deliver
  end
end

task :send_final_day_email => :environment do
  Enrollment.active.graduating_on(Date.today).each do |enrollment|
    EnrollmentMailer.graduation_letter(enrollment).deliver
    MentorMailer.confirm_grad(enrollment).deliver
  end
end

Plus several more notifications.

I wanted to test the code in this file, but as it is, it’s not very friendly to testing. However, there was a pattern among all these scheduled emails – grabbing specific enrollments and performing certain email actions. Sounds like a great use case for a service object.

Inspired by my functional approach to solving the verbal math problem in JavaScript, I decided to implement a similar approach in Ruby.

My first solution took advantage of Ruby’s everything-is-an-object nature, sending number objects symbols and values, which made solving the problem pretty easy.

However, it’s possible to take a functional approach in Ruby that is nearly equivalent to how you could solve this problem in JavaScript. And then, you can even combine this with Ruby’s object-oriented nature and metaprogramming capabilities to create a truly elegant solution.

While JavaScript has anonymous functions, Ruby has something similar in blocks, procs, and lambdas.

Here’s a language conversion to illustrate how you can achieve very similar functionality in Ruby and JavaScript (Check out my last post where I explain the JavaScript function in-depth):

JavaScript:

1
2
3
4
5
6

function plus(amount) {
  function add(number) {
    return number + amount;
  }
  return add;
}

I’m a fan of this fluent calculator exercise (I covered my solution using Ruby in my last blog post), and on another flight, I decided to implement a solution in JavaScript. Ruby’s object-oriented nature and metaprogramming capabilities made the task fairly simple; how would it go in JavaScript?

Recall that this exercise requires one to be able to verbally enter math operations, i.e. one(plus(one())), and return the correct integer result.

In Ruby, because most everything is an object, I was able to call methods on my integers, like 1.send(:+, 1). In JavaScript, integers are just primitive data types – not objects that can receive messages. But JavaScript’s ability to return functions allows us to achieve the same ability.

Again, I started off with the one() function. I knew one() would need to optionally take an argument, which would be an operator function. If no operator function was passed, I simply return 1. Otherwise, I need to return an operation on 1:

1
2
3
4
5
6
7

function one(opFunc) {
  if (opFunc == undefined) {
    return 1;
  } else {
    // as yet unwritten code
  }
}