Hey all,
I have two models in my rails project that share a lot of traits. They
each have the same 4 properties, and now I need to add 2-3 methods to
each one that will be the same. In the spirit of DRY I am looking for
a solution to write these methods only once.
Both of these models already inherit from ActiveRecord . . . and I
didn’t know if it was safe to just “whip up” a super class for them
both and have them inherit the methods from that(competent at rails
and ruby, but grasping for that intermediate level here). I know that
Enumerable is a mixin that is included in arrays and hashes, etc and
that I can create modules. (where should I put them in rails?). Does
anyone have any good information on subclassing in rails vs mixins?
Tutorials, good write ups or books to help me understand further? Even
your own advice would be great.
Thanks ahead of time
On Dec 9, 11:58 pm, BushyMark [email protected] wrote:
Hey all,
I have two models in my rails project that share a lot of traits. They
each have the same 4 properties, and now I need to add 2-3 methods to
each one that will be the same. In the spirit of DRY I am looking for
a solution to write these methods only once.
Both of these models already inherit from ActiveRecord . . . and I
didn’t know if it was safe to just “whip up” a super class for them
You can do that, as long as the base class has
class MyAbstractClass < ActiveRecord::Base
self.abstract_class = true
…
end
(or else rails will assume you’re trying to do single table
inheritance)
both and have them inherit the methods from that(competent at rails
and ruby, but grasping for that intermediate level here). I know that
Enumerable is a mixin that is included in arrays and hashes, etc and
that I can create modules. (where should I put them in rails?). Does
anyone have any good information on subclassing in rails vs mixins?
Doesn’t really matter. Rails will find them in the lib or models
folders among others.
Exactly when you go down either is a judgement call really.
Fred
Fred, thanks for the info!
I like the idea of creating a super class, if only for the naming
convention I have setup. I just wanted to check my syntax though.
The two models are called BlockSchedule and DaySchedule.
Lets say I wanted them both to inherit the properties of a class
called Schedule (see why I like the sub classing idea? easy to
remember naming conventions, 
). By your instructions I create the
class
class Schedule < ActiveRecord::Base
self.abstract_class = true
…[shared methods go here]
end
and DaySchedule I would re-write to be
DaySchedule < Schedule
…
end
And now DaySchedule’s class methods (everything from what I have
written to save, etc . . . stay the same?
Sorry if the question seems remedial, I really appreciate the help!
On Dec 9, 7:01 pm, Frederick C. [email protected]
I don’t know anything about your app, but if you don’t use STI (ie.
you leave abstract_class = true) you’ll never be able to tell the
difference b/n the two classes.
That is… you could…
create a BlockSchedule with ID=1
create a DaySchedule with ID=2
BlockSchedule.all => returns both records.
If you use STI it would only return the first. To get them all you’d
do Schedule.all
Anyway, maybe this isn’t what you want and if so ignore me 
On 10 Dec 2008, at 00:13, BushyMark wrote:
remember naming conventions, ). By your instructions I create the
end
And now DaySchedule’s class methods (everything from what I have
written to save, etc . . . stay the same?
That’s the theory!
Fred
On Dec 10, 3:02 am, Philip H. [email protected] wrote:
I don’t know anything about your app, but if you don’t use STI (ie.
you leave abstract_class = true) you’ll never be able to tell the
difference b/n the two classes.
That is… you could…
create a BlockSchedule with ID=1
create a DaySchedule with ID=2
BlockSchedule.all => returns both records.
That’s not true. With the parent class being an abstract class they’d
be in two completely separate tables.
Fred
Head First Design Patterns is an excellent book IMHO for OO
application design. It’s geared towards Java but it has excellent
points. One of them being ‘favor composition over inheritance’. The
use of modules in Rails gives so much flexibility that I think going
that route would be the best/simplest solution.
Pepe
BlockSchedule.all => returns both records.
That’s not true. With the parent class being an abstract class they’d
be in two completely separate tables.
Ah. Sweet! Didn’t know that. Thought from your other message that
toggle just told rails to stop looking around for STI (and the type
field). Good to know!