For what it’s worth, this case is easily a Ruby question too. Take a
Ruby angle not so much a Rails angle on this.
Well, yes and no. The object-oriented design and how to apply it in
Ruby part, that’s certainly a Ruby thing. But the what do I do about
the specifics of Rails’ architecture and where should I put stuff if I
refactor it, that’s very Rails-specific.
Honestly, though, my primary metric is thread quality. We have
interesting threads on R and Erlang on here sometimes. Rails is
certainly more relevant than that. It’s just that there are a lot of
totally underwhelming Rails questions that are kind of dispiriting.
It’s kind of a quality thing. A lot of times I just want to exclude
Rails questions on principle.
You need to separate out some of the functionality of your
controllers. Clearly they can both inherit common functions (methods)
from a parent class or from a module of some kind.
It really is a matter of that. It is a design issue.
Yes and no, I think. Rails’ MVC dirs do kind of put you in a bind in
the original poster’s use case, where you can’t map controllers to
models directly. To that extent it’s on the wrong list. That’s totally
just Rails stuff.
The more general topic of Ruby code getting too big, though, sure.
As for a class or set of classes (controller) growing large… this
is software. Every piece of functionality added will increase
complexity almost exponentially. It does become more difficult to
manage it mentally. That’s what documentation and notes are for. Pen
and paper become very nice tools at this point. Draw little diagrams
and illustrate your design somewhat. The Ruby way is generally pretty
good at keeping things smallish and manageable, and thus, self-
documenting to some degree, but at some point you can’t avoid
documentation and drawing.
Au contraire! That’s what refactoring is for.
By the way, one fun (but potentially risky) thing about Ruby is that
you can actually define one class throughout the course of very many
files. I talked to a Lisp diehard who liked Ruby because he could
dynamically extend different ActiveRecord models with different Ruby
modules depending on how they were instantiated. It sounded kind of
insane, in fact another guy at the same company told me he thought
Lisp was like Kaballah, in that it carries the risk of twisting your
brain permanently, but there’s a great deal of power in it. Anyway, it
does actually raise some genuine questions about how you keep that
twisty maze of passages all alike in some semblance of order. But that
is kind of generalized out from the OP’s actual question.