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 -~----------~----~----~----~------~----~------~--~---
