Split model with many attributes - ruby-on-rails

Question

I have a model Foo with a lot of attributes (generated by Paperclip, Devise and other things). Now my table have 43 columns.
The advantages and disadvantages are:
+ I respect the standard OOP.
- The creation of each model instance after a database select is longer.
- The .inspect method is hard to read (not the most important I think, and easy to override).
- The source code of the model takes more than 700 lines (can be solved using Concern)
My problem is that I don't need all theses informations on 90% of my website pages.
I thought of a solution, but need some expertise to know if this is a good or bad idea.
The idea is to cut the model into 2 parts: Foo and FooInfos, where:
Foo contains all the main informations
FooInfos contains all the informations for the 10% of the remaining pages, only loaded when necessary (with delegate method, e.g.)
a foo object has_one foo_info
With this method, all the advantes noted above becomes disadvantages and vice versa.
Is this a good idea ? Do you have some cases where this is not ? Do you have any other ideas ?
Regards

Answer 1

You're correct in that, as you described, your model Foo has too much information.
Just moving information into a generic FooInfos class/table will only mask the original problem behind an indirection, not solve it.
To point you into the right direction: asking "how to make this model smaller" is a first step, but you need to ask a slightly different question:
Does this class do exactly one thing? And if not, how do I separate concerns?
A variant of this would be: "What separate concerns are hiding inside this class?" There are multiple ways to split up the information and concerns hiding in a single page object.
Some tools:
1) isolate information
2) separate information into multiple models
3) STI (Single Table Inheritance)
4) Mixins
and many, many more
1) isolate information
Analyse your code and be watchful of the following: a set of methods is using a set of attributes and is using a separate view element. Or is generally accessed on model-level through a set of related interface methods.
Everytime you write a (bigger) new feature, ask yourself if that's really a feature belonging directly to the current model or if it's a model of it's own (or a helper model).
2) Multiple Models
You can split up some information like you described in your question: introduce another model (like FooInfo, but actually not like this!):
Don't just extract some meta-information, but make the model name matter!
For example:
Paperclip stuff can be extracted into an Attachment model, where a Page model can have one or many attachment models.
devise access rights stuff can be managed via CanCan
SidebarContent as a method to represent a page's information inside the sidebar
...
I'm sure you will find a lot of stuff inside your Page object that in reality is a separate concern.
You can still render the additional information via a partial and pass for example #page.sidebar to it, this way your Page view doesn't get too big. Also, in the backend you can use nested forms and partials, so on the outside the solution with several models will be no different from your current solution, but split up nicely into several concerns.
I did a quick google search on nested forms, and this came up: http://iroller.ru/blog/2013/10/14/nested-model-form-in-rails-4/
Don't know if it's any good, but in doubt you can always google yourself or get a book with examples on rails.
If you unload information to a different model, it will not only be still OOP, but even more so:
class Page < ActiveRecord::Base
has_one :sidebar
accepts_nested_attributes_for :sidebar
end
class Sidebar < ActiveRecord::Base
belongs_to :page
end
#page.sidebar # => very OOP!
3) STI (Single Table Inheritance)
Here's an official documentation page: http://api.rubyonrails.org/classes/ActiveRecord/Inheritance.html
Basically, you can move the information that's not needed on every page into some special cases:
class Page < ActiveRecord::Base
end
class ImprintPage < Page
def do_something_with_terms_and_conditions
end
end
class IntroPage < Page
has_one :logo
end
class Logo < ActiveRecord::Base
# paperclip stuff
end
You can even derive the Logo from Image, making it a special kind of Image (where Image contains all the paperclip stuff).
ActiveRecord will store the class type in the database, so you can do something like this in your view (pseudocode):
if #page.is_a?(IntroPage)
# render intro partial
4) Mixins
You can move concerns into mixins:
class Page
include PageTools::UserMethods
include PageTools::ImageHandling
end
But be very careful, since this might lead to information being all over the /lib folder, which might again be just disguising the original problem.
Conclusion
There's much more you can do to make a class/model less monolithic (for example Service Objects, Concerns). These are all just tools to implement some important principles: don't let your classes get big, and try to separate information/concerns/functionality often.
Most of it will come through practice, just never add a bunch of methods for a feature without asking yourself first if it has to really be inside this exact model - refactoring a huge Page monster model after it has grown too much is always painful!