"Mark Wilden" <[EMAIL PROTECTED]> writes: > On Fri, Sep 26, 2008 at 4:49 AM, Matt Wynne <span dir="ltr"><mailto:[EMAIL > PROTECTED]></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'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 [email protected] > 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 :) Pat _______________________________________________ rspec-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/rspec-users
