On Tue, 23 Nov 2004 10:30:17 -0000, Kerry <[EMAIL PROTECTED]> wrote: > IMHO, > the is a, has logic can easily be corrupted, just by carefully naming the > cfcs... > > machine.cfc is a > object.cfc > > a machine is an object..... > I don't think I really groked OO until I stopped thinking in terms of "is-a/has-a."
One CFC should extend another (or they should both extend a common base CFC) if they implement the same methods and have the same pre-conditions, post-conditions, and invariants. As you pointed out, the "is-a" relationship instead focuses on the name of the CFC, which is arbitrary, irrelevant to the compiler, and at best only provides a hint of what the CFC actually does. Also, I think the very notion that we need to decide between "is-a" and "has-a" suggests that we figure out what the CFCs are first and then figure out how they relate to each other. I haven't managed to get very far working that way. Instead I start my design off with one or two simple CFCs. As I look at the requirements and add features new CFCs emerge from refactoring. (The same is true whether I'm working with code or UML diagrams.) Patrick -- Patrick McElhaney 704.560.9117 http://pmcelhaney.blogspot.com ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at [EMAIL PROTECTED]
