# Subclassing vs mixins, which one should be used?

**URL:** <https://www.ruby-forum.com/t/subclassing-vs-mixins-which-one-should-be-used/155270>\
**Category:** Rails\
**Created:** [December 10, 2008, 12:58am UTC](https://www.ruby-forum.com/t/subclassing-vs-mixins-which-one-should-be-used/155270 "2008-12-10T00:58:41Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![bushymark](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/839c29/32.png) [@bushymark](https://www.ruby-forum.com/u/bushymark)\
**Post date:** [December 10, 2008, 12:58am UTC](https://www.ruby-forum.com/t/subclassing-vs-mixins-which-one-should-be-used/155270/1 "2008-12-10T00:58:41Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![bushymark](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/839c29/32.png) [@bushymark](https://www.ruby-forum.com/u/bushymark)\
**Post date:** [December 10, 2008, 1:02am UTC](https://www.ruby-forum.com/t/subclassing-vs-mixins-which-one-should-be-used/155270/2 "2008-12-10T01:02:11Z")

</div>

On Dec 9, 11:58 pm, BushyMark [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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

---

<div class="post-metadata">

**Author:** ![bushymark](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/839c29/32.png) [@bushymark](https://www.ruby-forum.com/u/bushymark)\
**Post date:** [December 10, 2008, 1:14am UTC](https://www.ruby-forum.com/t/subclassing-vs-mixins-which-one-should-be-used/155270/3 "2008-12-10T01:14:30Z")

</div>

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. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)

---

<div class="post-metadata">

**Author:** ![bushymark](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/839c29/32.png) [@bushymark](https://www.ruby-forum.com/u/bushymark)\
**Post date:** [December 10, 2008, 4:03am UTC](https://www.ruby-forum.com/t/subclassing-vs-mixins-which-one-should-be-used/155270/4 "2008-12-10T04:03:34Z")

</div>

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 🙂

---

<div class="post-metadata">

**Author:** ![bushymark](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/839c29/32.png) [@bushymark](https://www.ruby-forum.com/u/bushymark)\
**Post date:** [December 10, 2008, 1:20am UTC](https://www.ruby-forum.com/t/subclassing-vs-mixins-which-one-should-be-used/155270/5 "2008-12-10T01:20:55Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![bushymark](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/839c29/32.png) [@bushymark](https://www.ruby-forum.com/u/bushymark)\
**Post date:** [December 10, 2008, 10:01am UTC](https://www.ruby-forum.com/t/subclassing-vs-mixins-which-one-should-be-used/155270/6 "2008-12-10T10:01:04Z")

</div>

On Dec 10, 3:02 am, Philip H. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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

---

<div class="post-metadata">

**Author:** ![bushymark](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/839c29/32.png) [@bushymark](https://www.ruby-forum.com/u/bushymark)\
**Post date:** [December 11, 2008, 2:25am UTC](https://www.ruby-forum.com/t/subclassing-vs-mixins-which-one-should-be-used/155270/7 "2008-12-11T02:25:25Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![bushymark](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/839c29/32.png) [@bushymark](https://www.ruby-forum.com/u/bushymark)\
**Post date:** [December 10, 2008, 7:10pm UTC](https://www.ruby-forum.com/t/subclassing-vs-mixins-which-one-should-be-used/155270/8 "2008-12-10T19:10:51Z")

</div>

> > 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!