Sounds about right.
Also worth noting that if some part of your app gets a generic contact
lobbed at it and it *really* needs to know which kind it is, it can just ask
it. Having isEmail(), isPhone() methods kind of undermines the polymorphism
(because you're just going to use them to write some conditional logic,
right?) and externalizes the object behaviour, but you *can* use them to get
you out of jail while you're contemplating the right refactoring or maybe
just focussing on the next paying gig.
Plus there's something that just tickles me about writing:
PhoneContact:
isPhone: return true;
isEmail: return false;
I picture someone consulting a traveller's phrasebook, marching up to a
policeman and demanding "Are you a telephone?".
Jaime
> -----Original Message-----
> From: [email protected]
> [mailto:[EMAIL PROTECTED] On Behalf Of Judah McAuley
> Sent: Thursday, 13 November 2008 4:02 PM
> To: [email protected]
> Subject: [CFCDEV] Re: Is inheritance the right choice here?
>
>
> Right, I think I get what you are saying. This appears to be
> a good example of polymorphism.
>
> I was hung up thinking of an object like a record from a db
> table. In a list of records from a db table, every row needs
> to have exactly the same set of columns.
>
> In this case, I could have a list of Contacts but each
> Contact doesn't have to look the same. There are no problems
> if a Contact that is of type Phone extends the base contact
> with attributes of phone number and the next Contact is of
> type Email and extends the base contact with attributes of
> subject and body. In both case, I'd have a
> sendReminder() function that was defined in the sub-class and
> shows up in the AbstractContact that is returned to my application.
>
> My view and processing pages and such are still going to have
> to know what the attributes in a Contact of type email are
> and that they are different than one of type phone, but
> that's ok because it would have to know that in my first
> scenario anyway, those details would just be down a level in
> a sub-structure.
>
> That understanding all sound solid so far?
>
> Judah
>
> On Wed, Nov 12, 2008 at 9:34 PM, Jaime Metcher
> <[EMAIL PROTECTED]> wrote:
> >
> >
> > Yes. Nothing really wrong with the other approach, it amounts to
> > about the same thing in terms of the data. Where the two
> approaches
> > diverge is when you start adding behaviour. Think of an operation
> > that in principle applies to any contact, but the details
> will differ
> > depending on the method - say you want to send a reminder
> to the user.
> > In the first approach,
> > contact.sendReminder() would contain a case statement - if
> method is
> > "email", email a reminder, if "phone" send a pre-recorded message,
> > maybe send an SMS etc. In the second approach,
> sendReminder() would
> > simply be implemented differently in each subclass. No ifs or case
> > statements. It means that AbstractContact actually doesn't need to
> > know what the methods are.
> >
> > This is called the "replace conditional with inheritance" pattern.
> >
> > Jaime
> >
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"CFCDev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/cfcdev?hl=en
-~----------~----~----~----~------~----~------~--~---
