On Fri, Sep 26, 2008 at 4:49 AM, Matt Wynne <[EMAIL PROTECTED]> 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'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's exactly like a Task (again, in the context of my program). That's an "is-a" relationship that inheritance was designed for, and it'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'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@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
