On Fri, Sep 26, 2008 at 11:46 AM, Pat Maddox <[EMAIL PROTECTED]> wrote:
> "Mark Wilden" <[EMAIL PROTECTED]> writes: > > > 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). > 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. It could have all those things, but it doesn't. :) The program is a Getting Things Done-type task manager (called giterdone). It couldn't care less who the appointment is with. It just knows that an Appointment is something that needs to "get done." The appointment's location is handled by a GTD context, just like any other Task. The only difference is that this kind of Task can only be done on a particular day. If you don't giterdone on that day, it falls off the schedule. 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. A Project is another kind of Task - a sibling to Appointment - and can have multiple Tasks (including Appointments). This again is in line with the GTD philosophy, which draws a clear distinction between things with "next actions" and things without (like a project). 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. Well, I do say YAGNI. Or at least YPAGNI. And again, if this turns out to be incorrect, I'll change it. I really do believe in trying the simplest thing that could possibly work. I've used STI on another side project of mine (a magic trick database, called abracadata), and it actually did work pretty damn perfectly. But if it turns out to be the wrong decision, I'll embrace that change. However, I do admit that I'm biased in favor of inheritance where it applies - I've been using it since 1989, after all. Prior to that time, I was implementing it in C before I knew what it was called. I really like the idea of "this thing is like that thing except for one little difference." On the other hand, I have been bitten by using inheritance where composition would have been a better design. I think the last time that happened was in 1991. :) And I think it's perfectly acceptable to talk about OOD because design > is one of the key benefits of BDD :) > Coolness. ///ark
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
