I was ready to implement the image upload handling for pulling in images effortlessly to blogs, but I thought I'd first take the time to refactor a lot of the duplicate code that I hacked together "just to make it work". Fortunately, I had good test coverage, so the refactoring was pleasant.
I began by pulling out common behavior of documentable things into shared examples for Rspec, to dry up the tests, and then moved into pulling out common functionality from the
Project models into Concerns.
The more I cleaned up the code base, the more it became apparent that there were some interdependencies between what I was calling documentable and what I was calling picturable; i.e. those objects which could associate with a set of pictures. The problem chiefly, was that documentable's had to know about pictures to "render" them.
Ultimately, it seemed to make more sense to pull out the common functionality into a parent class: Document from which the article and project would inherit. After all, both of these things are Documents; both in the software and real world, each represent entities of documentation.
There are slightly different business rules between articles and projects; most notably, that a project can have many associated articles. Otherwise, they are very similar, and both can reference pictures.
Why not just use Articles and "tag" them with a project title? Well, as discussed before, Projects themselves have extra information in this blog. They may contain future meta data, but specifically, there is a "Project Page" that can describe the project at higher level, and I might have projects that were either older and/or don't have any associated articles.
Still Curious About Composition
At this point, I can't decide if this is the best architecture, or if it merits further refactoring. The similarities between the two main models are great, but that could change in the future. As long as I have a good suite of tests, I'll be in a position to continually improve the code in the future.