Need explicit waitlist in domain model

[SaintGimp]

Right now retreats have a list of registrations. Each registration may have a bed code if the participant has been assigned a bed (and is therefore officially registered) or a null bed code if the participant is on the waitlist for the retreat. This works ok but it's already caused multiple bugs in the code where we didn't expect bed codes to be possibly null.

Rather than having to test and protect against null bed codes all the time it would probably be better to have an explicit waitlist in the domain model which is just a joining of participants and retreats without any bed code at all. On the negative side, you'd need to deal with both collections if you want to display a unified list of both registered and waitlisted participants, but on the positive side the intention would be more explict and there would be fewer opportunities for bugs.

I'm going to work on this shortly unless someone else has a better idea.

[NotMyself]

Why not allow the registration to determine the type of registration. Something along the lines of thishttp://yuml.me/diagram/scruffy/class/%5BRegistration%5D%5E%5BConfirmedRegistration%5D,%20%5BRegistration%5D%5E%5BWaitlistRegistration%5D.. With the bed code value being the discriminatorhttp://jagregory.com/writings/fluent-nhibernate-subclass-syntax-changes/. Then it is a simple matter of exposing a couple properties that filter by type to visualize the registered folks with the wait listed folks.

On Thu, May 26, 2011 at 10:57 AM, SaintGimp < reply@reply.github.com>wrote:

Right now retreats have a list of registrations. Each registration may have a bed code if the participant has been assigned a bed (and is therefore officially registered) or a null bed code if the participant is on the waitlist for the retreat. This works ok but it's already caused multiple bugs in the code where we didn't expect bed codes to be possibly null.

Rather than having to test and protect against null bed codes all the time it would probably be better to have an explicit waitlist in the domain model which is just a joining of participants and retreats without any bed code at all. On the negative side, you'd need to deal with both collections if you want to display a unified list of both registered and waitlisted participants, but on the positive side the intention would be more explict and there would be fewer opportunities for bugs.

I'm going to work on this shortly unless someone else has a better idea.

Reply to this email directly or view it on GitHub: https://github.com/HarmonyHacks/Dahlia/issues/22

"The explanation requiring the fewest assumptions is most likely to be correct."

• Occams Razor http://en.wikipedia.org/wiki/Occam's_Razor

[SaintGimp]

Yes, that might work if the base Registration has only a retreat and a participant, a WaitListedRegistration has the same thing, and a ConfirmedRegistration adds a Bed property. (Doing it the other way around would be a Liskov violation, which is basically what's wrong with the current code, see #18.) Not totally convinced though - I know it feels like there's an "is-a" relationship in there somewhere but I'm not sure that there is, actually. I'm having a hard time coming up with scenarios where it would be useful to deal with a list of base Registration objects without distinguishing between subtype in some way.

I also thought about using the Null Object pattern where waitlist registrations point to a specific "waitlisted" Bed object so that you can treat them all the same but that also seems like an abuse of the domain.

I know I'm putting a lot of thought into what seems to be a trivial problem but this turns out to be surprisingly difficult to model correctly.