---
title: Unobtrusive Ruby
teaser: Thoughts on ruby that lets you work.
tags: web,good code,ruby
author: Mike Burns
published_on: 2011-09-12
---

Unobtrusive Ruby is any **Ruby code that stays out of your way**. It does not
make you write lots of boilerplate, or stub methods, or open classes. It is
**decoupled**. Its **tests run quickly**, its **classes fit on one screen**, its
**methods are tiny**, and it is **quickly refactorable**.

Unobtrusive Ruby is a state of mind. Unobtrusive Ruby is **what you want your
friends to write**.

Since you love your friends, here are some guidelines while you design your next
gem or framework:

## Take objects, not classes

All your arguments should be instantiated objects, where the caller has invoked
the `.new` method herself. **Leave the constructor up to the class author**.
Never force a calling convention on a constructor, or in any way force someone
to look up how to instantiate her own class.

## Never require inheritance

Object inheritance is one way to force the user—your friend—to do odd things
with the constructor. When to call super, what the arguments are, and so on.
This goes for mixins, too; they add complexity to the class's namespace,
increasing the cognitive overhead. All **inheritance adds brittleness**.

## Inject dependencies

The contents of a class should **mention no other classes by name**. Pass in all
objects that it must use. Not only will you thank yourself for the flexibility
later, you'll notice that your tests are better at the beginning.

## Unit tests are fast

A unit test on a small class should be fast, and classes should be small. Mock
objects, a lack of inheritance, and dependency injection will see to it. The
tests for your friend's code should not have the same dependencies as the tests
for your own code. **The ideal dependencies are nothing more than the test
framework and the class under test**.

## Require no interface

Classes should care about composing instead of being composed. The best class
will **consume instead of being consumed**. It makes its own rules. Maybe you
can't get there—something has to be consumed at some point—but it's a useful
goal. If it's not possible, the required interface must be simple. One method,
maybe two.

## Data, not action

Data is easy to test: pass some values into a method, receive a value from the
method, then verify that it's the right value. Never force your friend to do
anything more than this. Never force them to do database lookups, system calls,
random number generation, and so on; **do that for them**.

## Always be coding

The overall idea here is that your friend should always be able to just write
code. You never want to stand in her way; never force documentation or change
her classes or invent bizarre loopholes. You, as the gem author and framework
designer, want your friends to **build their system without noticing the system
you've built**.

Unobtrusive Ruby does **what you expect**.