There’s been a lot of debate in the Rails community about object-oriented programming lately. Some have complained that Rails conventions don’t really let you “objectify” your application very well. Others have argued that Rails was never meant to be a OOP framework, and that it mixes functional and object-oriented programming in a fashion that fits the “Rails way.” In the midst of all of this, James Golick of BitLove has released an excellent gem called “objectify” [1] that approaches this problem and attempts to make Rails a bit more object friendly. I personally would argue that it’s the very nature of MVC architecture that makes it difficult to use your objects the way you might want to, and not so much the Rails framework itself.

Here’s some good news: none of this should really matter too much to you. There’s a lot of different ways to approach organizing your Rails app, but whichever way you choose you can still make OOP work for you. You can take patterns that work for you and the good parts of OOP and still use them in your app. You can extract parts of your Rails models and decouple them from ActiveRecord to make testing them easier and faster.

Lets start off simple and take the concept of encapsulation for example. Good object design encapsulates the associated logic in itself. Let’s take an example of code that does not follow this principle:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

class ConfirmationMailer
  def self.send_to_user!(user)
    # send a confirmation email to a user
  end

  def self.send_to_guest!
    # send a confirmation email to a guest
  end
end

if current_user
  ConfirmationMailer.send_to_user!(current_user)
else
  ConfirmationMailer.send_to_guest!
end

I see this as poorly written code, because the domain logic of the object sits outside of its class. A better implementation might look like this:

1
2
3
4
5
6
7
8
9
10
11

class ConfirmationMailer
  def self.send!(user)
    if user
      # send a confirmation email to a user
    else
      # send a confirmation email to a guest
    end
  end
end

ConfirmationMailer.send!(current_user)

Not only do we have less lines of code here, but we have a more encapsulated object that handles its own logic. We’re relying on the object to be self-sufficient enough to accept a parameter and know what to do with it.

This also opens our class up for flexibility. What if we wanted to send a confirmation e-mail to a user other than the current user, just as an administrator might want to do? With our first example, we cannot easily do this without duplicating some code. With our second example, it’s very easy to do this with virtually no code duplication.

This is just one example of using good OOP in your Rails app. You needn’t be too worried about opinionated Rails development. Take principles that work well for you and enjoy them.

[1] Just a little fun side note. BitLove is the brains behind the popular fetish/BDSM social networking site FetLife. I can’t help but think that the choice of name here, “objectify”, is not a coincidence :)