chip@tct.com (Chip Salzenberg) (04/11/91)
According to cok@islsun.Kodak.COM (David Cok): >In article <28007BC8.D71@tct.com> chip@tct.com (Chip Salzenberg) writes: >>Or (another choice): modify the base class for the added functionality >>(add a do-nothing virtual function, etc). That's my choice. > >You left off the rest of my statement: > >>> ... or corrupting the base class with the interface to the added >>> functionality of the derived class. I apologize to David for not thoroughly reading his article. He did, indeed, anticipate my "modify the base class" suggestion. >I just can't see that modifying the base class is a generally reasonable >alternative -- even if you do have source code access, which in general you >do not. Why should the added functionality of derived classes have to be >propagated up the inheritance tree? I modify the base class *only* if I can answer this question in the affirmative: Might code dealing with a |Base*| reasonably want to perform this operation? Or, in other words: Is this a reasonable |Base| operation that was omitted due to oversight, which I may now be able to rectify? If I cannot answer "yes" to the above questions, then I must conclude that the feature in question is specific to the derived class. In such a case, I do NOT modify the base class. BUT, don't jump to conclusions. NEITHER do I make a habit of casting |Base*| to |Derived*|. Instead, I take care in my code never to lose the static type of a Derived object in any circumstance that might require the use of Derived-specific features. This policy is a rather messy compromise, but it has worked so far. -- Brand X Industries Custodial, Refurbishing and Containment Service: When You Never, Ever Want To See It Again [tm] Chip Salzenberg <chip@tct.com>, <uunet!pdn!tct!chip>