Most Rails applications suffer from several Large Classes. Large
classes are difficult to understand and make it harder to change or
reuse behavior. Tests for large classes are slow and churn tends to be
higher, leading to more bugs and conflicts. Large classes likely also
suffer from divergent
In general, public methods are a greater liability than private
methods. This is because it’s harder to tell where public methods are
used, so you need to take greater care when refactoring them. However, a
large suite of private methods is also a strong indicator of a large
Private methods can’t be reused between classes, which makes it more
likely that code will be duplicated. Extracting private methods to new
classes makes it easier for developers to do the right thing.
Additionally, private methods can’t be tested directly. This makes it
more difficult to write focused, simple unit tests, since the tests will
need to go through one or more public methods. The further a test is
from the code it tests, the harder it is to understand.
Lastly, private methods are often the easiest to extract to new
classes. Large classes can be difficult to split up because of entangled
dependencies between public and private methods.
Attempts to extract public methods will frequently halt when shared
dependencies are discovered on private methods. Extracting the private
behavior of a class into a small, reusable class is often the easiest
first step towards splitting up a large class.
Keeping a class’s public interface as small as possible is a best
practice. However, keep an eye on your private interface as well. A maze
of private dependencies is a good sign that your public interface is not
cohesive and can be split into two or more classes.
A particular specimen of large class affects most Rails applications:
the God class. A God class is any class that seems to know everything
about an application. It has a reference to the majority of the other
models and it’s difficult to answer any question or perform any action
in the application without going through this class.
Most applications have two God classes: the user, and the central
focus of the application. For a todo list application, it will be user
and todo; for photo sharing application, it will be user and photo.
You need to be particularly vigilant about refactoring these classes.
If you don’t start splitting up your God classes early on, it will
become impossible to separate them without rewriting most of your
Treatment and prevention of God classes is the same as for any large
The canonical reference for writing fantastic Rails applications from authors who have created hundreds.