Rails - Dec 2008 - subclassing vs mixins, which one should be used?

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
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Dec 9, 11:58 pm, BushyMark
<bushym...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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
> Tutorials, good write ups or books to help me understand further? Even
> your own advice would be great.
>
> Thanks ahead of time
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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 Cheung
<frederick.che...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On Dec 9, 11:58 pm, BushyMark
<bushym...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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
>
> > Tutorials, good write ups or books to help me understand further? Even
> > your own advice would be great.
>
> > Thanks ahead of time
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On 10 Dec 2008, at 00:13, BushyMark wrote:
>
> 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?
That''s the theory!

Fred
>
> Sorry if the question seems remedial, I really appreciate the help!
>
>
>
> On Dec 9, 7:01 pm, Frederick Cheung
<frederick.che...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> wrote:
>> On Dec 9, 11:58 pm, BushyMark
<bushym...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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
>>
>>> Tutorials, good write ups or books to help me understand further?  
>>> Even
>>> your own advice would be great.
>>
>>> Thanks ahead of time
> >

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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 Dec 9, 2008, at 4:13 PM, BushyMark wrote:
>
> 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 Cheung
<frederick.che...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> wrote:
>> On Dec 9, 11:58 pm, BushyMark
<bushym...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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
>>
>>> Tutorials, good write ups or books to help me understand further?  
>>> Even
>>> your own advice would be great.
>>
>>> Thanks ahead of time
> >

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Dec 10, 3:02 am, Philip Hallstrom <phi...-LSG90OXdqQE@public.gmane.org>
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
>
> 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 :)
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

> On Dec 10, 3:02 am, Philip Hallstrom
<phi...-LSG90OXdqQE@public.gmane.org> 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.
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!

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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

On Dec 10, 1:09 pm, Philip Hallstrom <phi...-LSG90OXdqQE@public.gmane.org>
wrote:
> > On Dec 10, 3:02 am, Philip Hallstrom
<phi...-LSG90OXdqQE@public.gmane.org> 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.
>
> 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!
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---