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

Mark Wilden mark at mwilden.com
Fri Sep 26 15:48:48 EDT 2008

On Fri, Sep 26, 2008 at 11:46 AM, Pat Maddox <pergesu at gmail.com> wrote:

> "Mark Wilden" <mark at mwilden.com> 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&#39;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 :)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20080926/57817a3c/attachment.html>

More information about the rspec-users mailing list