Has anyone ever published a good article about the expense of long inheritance chains in ColdFusion and their affect on system performance? I am not questioning validity, I'm curious if there are hard (or soft) facts out there since I've never really looked.
Adam Haskell On Fri, May 9, 2008 at 9:55 AM, Brian Kotek <[EMAIL PROTECTED]> wrote: > In general, yes, that is part of the point of a superclass: to avoid > duplication in the child classes for common behavior. (The real purpose of > superclasses is polymorphism but that is another topic). > > In theory one should only put behavior in the superclass if it is shared by > *all* of the subclasses. If some subset of the subclasses has duplicate > behavior, then another layer of inheritance may be necessary to stick to > this rule. In practice (and especially in CF where long inheritance > hierarchies get expensive) the answer is less clear. I would say that, > pragmatically, you could just go ahead and do it, and refactor later if > there any issues arise. > > > On Fri, May 9, 2008 at 9:44 AM, Dawson, Michael <[EMAIL PROTECTED]> > wrote: > >> I have been building some services for our Cisco IP phone network. Each >> phone is both a web client and a web server. You interact with the phones >> by publishing or pushing XML via HTTP. >> >> Cisco has defined a small set of XML definitions that perform different >> actions on the phones. Most of the XML definitions contain the same tags >> (Title, Prompt, SoftKeyItems). Conversely, some tags (Text, Height, >> Width) are used in about half of the XML definitions. >> >> I created a CFC for each XML definition (CiscoIPPhoneText.cfc, >> CiscoIPPhoneMenu.cfc), but found that some methods, setTitle() and >> setPrompt(), were duplicated in most CFCs. So, I then created a parent CFC, >> CiscoIPPhoneBase.cfc. I moved setTitle() and setPrompt() to the base CFC. >> That seemed to be the correct thing to do. >> >> Each "child" CFC has a build() method that generates the XML packets using >> the getXXX() methods. >> >> Now, I have found that there are some other methods that are duplicate, >> but not in the majority of XML definitions: setText(), setHeight(), etc. >> >> Since those "occasional" tags appear in more than one XML definition, >> would it be correct to also place them in the base CFC? >> >> My thought is that the base CFC should hold every method that could be >> duplicated, even if only once. >> >> Is there anything wrong with what I'm doing? >> >> Below are two example XML packets that are requested by the phones. >> Notice there are some attributes that are common with most XML definitions. >> >> <CiscoIPPhoneText> >> <Title>This is the top line of the display</Title> >> <Prompt>This is the bottom line of the display</Prompt> >> <Text>This area is simple text with only line feeds, carriage returns >> and tabs</Text> >> <SoftKeyItem> >> <Name>Button Name 1</Name> >> <URL>Button Action 1</URL> >> <Position>Button Location 1</Position> >> </SoftKeyItem> <SoftKeyItem> >> <Name>Button Name 2</Name> >> <URL>Button Action 2</URL> >> <Position>Button Location 2</Position> >> </SoftKeyItem> >> </CiscoIPPhoneText> >> >> <CiscoIPPhoneMenu> >> <Title>This is the top line of the display</Title> >> <Prompt>This is the bottom line of the display</Prompt> >> <MenuItem> >> <Name>Display Text 1</Name> >> <URL>Menu URI 1</URL> >> </MenuItem> <MenuItem> >> <Name>Display Text 2</Name> >> <URL>Menu URI 2</URL> >> </MenuItem> >> <SoftKeyItem> >> <Name>Button Name</Name> >> <URL>Button Action</URL> >> <Position>Button Location</Position> >> </SoftKeyItem> >> </CiscoIPPhoneMenu> >> >> >> Thanks >> m!ke >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
