In our example, there are no fat models in charge of doing too many things. Recording::Incineration or Recording::Copier are cohesive classes that do one thing. Recording::Copyable adds a high-level #copy_to method to Recording’s public API and keeps the related code and data definitions separated from other Recording responsibilities. Also, notice how this is just good old object orientation with Ruby: inheritance, object composition, and a simple design pattern.
Source: 37signals Dev — Vanilla Rails is plenty
This is an “implementation” of my guiding philosophy of programming:
If you truly understand the process you’re trying to implement, the code will “fall out.”
This article is discussing adding a Rails concern for making ActiveRecord objects copyable and “incineratable,” and then implementing these operations in PORO models. That’s great, but this sort of redirection is only needed to commonize the human-to-machine naming that might be used for different classes in the application. (There’s probably a term for this, but conceptualizing the terminology used in classes and methods is an art unto itself.)
I don’t think I’ve ever written a concern, but, then, I’ve never written a Rails application (out of at least a dozen and a half now), with 500 classes, which would inevitably have some overlap in their “business” functionality. My current app is the most complex thus far, and it only has 52.
If you don’t have that situation, you don’t need this level of abstraction, and, and — and here’s the important part — if you do have that situation, you will find yourself starting to write duplicated code. When this happens, as a programmer, your “spidey sense” should start tingling, and telling you there’s another level of abstraction to implement.
And that’s what I mean about the code “falling out” of implementing the actual process of what you’re trying to program.
I suppose there’s a case to be made here that you might wind up with duplicated code on a large codebase, simply because one programmer didn’t know what another programmer had done, but these kinds of things will happen. Refactoring the duplication, once discovered, is just part of the job.