5 Simple Rules to Good OO in Rails

Rules are a novel idea. Rule aren’t guidelines or suggestions or hints; rules are the law. When a developer says they have a set of rules for how to approach a particular concept there is generally a bunch of hemming and hawing and teeth sucking. This is generally followed by shallow attempts at poking holes in the rules or finding edge cases.

Keeping that in mind, I’d like to introduce you 5 simple rules that can make your attempts at great Object Oriented-ness even easier. Before I introduce these rules, I’d like to thank Sandi Metz for originally sharing them. Her book, Practical Object-Oriented Design in Ruby, has made me rethink how I approach OO. It is confidence-inspiring to see that you’ve independently come to many of the same conclusions of a fantastic book.

Rule: Your class can be no longer than 100 lines of code.

Obviously, a long class contains more code than a shorter class. Working towards shorter classes means it will be less likely that your classes will enclose more than one responsibility. Less code also means that it’ll more likely that your entire class will fit on one screen in your editor with out scrolling.

Rule: Your methods can be no longer than five lines of code.

Short methods are generally easier to read than longer methods. Short expressive methods also don’t require comments, so the reader can understand its functionality easier.

Rule: You can pass no more than four parameters.

Passing more than four parameters to a method often signifies that you are missing some sort of encapsulation. Keep in mind that the number four might sound arbitrary, seeing that it is only more more than three and one less than five, but having a finite cut off point will reduce hesitation. You don’t question why 42 is the answer to the ultimate question of life, the universe, and everything, do you?

Rule: Rails controller actions can only instantiate one object.

With the move to Fat Models in Rails and beyond, controllers have been getting skinnier. The issue here is that decisions are still being made in the controller. In Rails, your controller is the coordinator that takes parameters and returns HTML, JSON or some other format. It shouldn’t be making decisions above that.

Also, there is no such thing as a service object in Rails. What people refer to as a service object is just another object that does something. Hopefully it is only one something.

Rule: You can pass only one instance variable to a view.

This is a simple rule. One instance variable in your view. More than one is illegal. Embracing this constraint will force you think about just what you are passing from the controller to view; it isn’t always just a collection of objects or even a single object.

Now what?

Following these rules will make your Rails code better, but there is a caveat. Following these rules blindly will not help you in the least. The trick to these rules is understanding why they are rules in the first place. The rules are simplistic, but understanding how to follow them can expose places in your code that might need to be re-evaluated for clarity and adherence to Object Oriented principals. These rules exist, so you as a developer can think less about how, and more about why.

Also keep in mind there is no silver bullet or single guide you can read to write better code. The key here is to understand the benefits that thinking about Object Oriented design when developing.

Have more thought this? Complaints? Want to wish me a happy birthday? Let me know on Google Plus or Twitter.