[rspec-users] RSpec makes me want to write better code

Pat Maddox pergesu at gmail.com
Fri Sep 26 14:46:21 EDT 2008

"Mark Wilden" <mark at mwilden.com> writes:

> On Fri, Sep 26, 2008 at 4:49 AM, Matt Wynne <span dir="ltr"><mailto:matt at mattwynne.net></span> wrote:
> Also why is the article so down on STI? What are the drawbacks? What
> do people use instead?I think the guy is really just down on
> inheritance itself, which is not an unusual nor even entirely
> unjustified attitude. Ruby has far less need to use inheritance
> because of the ability to mix in modules. And using it, particularly
> beyond two levels deep, can most definitely lead to nightmarish code,
> where changing one line in a parent class can make you spend an hour
> (or a day) trying to figure out how to handle the repercussions to
> every child class.  But I do believe that where a true "is-a"
> relationship exists, inheritance is often the best approach. I&#39;m
> working on a program right now that has a Task class and an
> Appointment subclass. An Appointment (in this context) is simply a
> Task that can only be performed on one day. Otherwise it&#39;s exactly
> like a Task (again, in the context of my program). That&#39;s an
> "is-a" relationship that inheritance was designed for, and it&#39;s
> working quite well. And, as an agile practitioner, if I find that this
> relationship changes I would throw out this class hierarchy.  STI is
> just a way to map inheritance to the database. I used it before I knew
> what it was called. If you do use inheritance with models, I think
> it&#39;s the best Rails way to persist the data.  Hmmm. Just realized
> that all this has nothing to do with RSpec....///ark
> _______________________________________________ rspec-users mailing
> list rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

fwiw, my inclination would still be to model this with composition
rather than inheritance :) An Appointment in the simplest case is just a
DateTime, but you can imagine it having a Location, Participants, and of
course a Task.  If it can have a Task, it can probably have multiple
Tasks.  And you can imagine Task evolving independently of Appointment,
for example a composite Task, or tasks requiring follow-up tasks under
certain conditions.  You can say YAGNI of course, but I think by
splitting those out entirely, you gain a more flexible model without
introducing complexity, and you avoid the technical stickiness that
accompanies STI in Rails.

And I think it's perfectly acceptable to talk about OOD because design
is one of the key benefits of BDD :)


More information about the rspec-users mailing list