very descriptive and understandable answer, thanks Isaac. i am only just getting my head round OO and appears i must have misunderstood the argument. thanks to you and Andrew setting me straight
thanks again >> however some people have put over an argument to do with this could >> be problematic when it comes to cfc's that extend each other, and >> therefore they take the preference that declaring all properties with >> varables.#beanname# would be better. > >I would contend that represents an unusual notion of what an object is >and what "extending" an object means. > >Extends represents and "is-a" relationship, not a "has-a" relationship. >That being the case, it's natural (and even desirable/expected) for >properties of the child class to *replace* properties of the parent >class as a part of the technique of polymorphism. So they're describing >as "problematic" something that is the expected/intended behavior with >OO systems. > >Class: Primate > Properties: > HeartRate 10 > MuscleDensity 10 > Diet x,y,z > >Class: Human -> Extends Primate > Properties: > MuscleDensity 3 > Diet a,b,c > >Class: Chimpanzee -> Extends Primate > Properties: > HeartRate 12 > MuscleDensity 12 > >Here we have a class hierarchy showing humans and chimpanzees both as >part of the taxonomy of "primates". Each sub-class has overwritten a >couple of the base properties of Primate. Neither of them should know >what the base values of those proeprties are -- that is, objects of type >"human" *should* be ignorant of the diet or muscledensity of a generic >"primate" because it doesn't pertain to the behavior of a human object. >chimpanzees *should* be ignorant of the HeartRate and MuscleDensity of >a generic "primate" because it doesn't pertain to the behavior of a >chimpanzee object. > >They do share some of the properties of generic primates. Humans share >the heart rate and chimpanzees share the diet. However even when they do >share properties, they *should* be ignorant of the fact that they share >those properties with the parent class. They should know only what the >value is, not where it came from. > >Keeping all the properties in one place keeps the subclasses ignorant >the way they should be. If you separate the properties for each class in >the inheritance chain (into a struct for each class), then you lose the >ability to properly perform polymorphism. > >If you find yourself in a situation where it seems like the current >object should know both values of the parent class and values of the >subclass, the likelyhood is that you've misused the extends attribute >and should probably not be using inheritance in that case, but rather >composition instead. Generally speaking composition should be preferred >over inheritance. There are plenty of cases where inheritance is useful >but if you find yourself thinking "but I don't know the value of >property x from my parent class", ask yourself again "is my subclass a >type of my parent class?" ... > >Is "engine" really a type of "car" or should maybe the car "have" an >engine instead? > > >-- >s. isaac dealey ^ new epoch > isn't it time for a change? > ph: 781.769.0723 > >http://onTap.riaforge.org/blog ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to date Get the Free Trial http://ad.doubleclick.net/clk;203748912;27390454;j Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:312486 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
