> 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:312432
Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm
Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
