Yes thank you. it is clear to me. I guess that I was thinking of
inheritance in a more broad sense than it really is. I've learned
about classes, sub-classes and super-classes in some of my programming
classes but putting this stuff to practice is much different.
It seems actually having use cases for the animal -> dog -> retriever
type of relationship doesn't happen all that often. At least it hasn't
in my app yet.
On May 2, 11:28 am, Nando <[EMAIL PROTECTED]> wrote:
> The part about PaternalLine tries to explain how the term "inheritance" came
> about. In the example, I'm probably mixing in too many concepts at once, and
> not doing a good enough job of explaining them in separate examples. Sorry.
> Let's leave that aside for a moment.
>
> To my mind, you can go 2 ways. One is that you can use inheritance, but then
> you'll need to instantiate ImageService, and probably create a few other
> similar objects like TextService for instance to handle text. ContentService
> would most likely NOT be instantiated. Content Service would contain methods
> common to handling both text and images, whereas TextService would contain
> methods specific to text (if there are any), and ImageService would handle
> methods specific to images. If that sounds appropriate, then you'd use
> inheritance and place the extends attribute in TextService and ImageService
>
> <cfcomponent displayname="TextService" extends="ContentService">
>
> Again, to use inheritance, you'll need to refactor your application to
> instantiate TextService and Image Service, rather than ContentService.
>
> If you want to stick with using Content Service, then you'll need to either
> pass an instance of ImageService into ContentService, or create an instance
> of ImageService inside ContentService, most likely when ContentService is
> instantiated.
>
> Are you clear how to do that yet?
>
> On Fri, May 2, 2008 at 4:11 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> wrote:
>
>
>
> > Ok so using this PaternalLine idea, in the parent (which for me is
> > contentService) it still needs an instance of the child (imageService)
> > in order to perform any of its functions.
>
> > How does the child perform a function of the uncle when they are both
> > essentially children of PaternalLine? This is how I see the
> > relationshis the way you explain it, looking just at inheritance:
> > PaternalLine -> Father -> Child
> > PaternalLine -> Uncle
>
> > The way I see this the child still needs an instance of uncle in order
> > to perform its functions. So essentally this isn't inheritance
> > anymore, its composition... Please explain further if It seems that I
> > am missing something.
>
> > On May 1, 7:14 pm, Nando <[EMAIL PROTECTED]> wrote:
> > > You have a class called ContentService. You notice that besides dealing
> > in
> > > generic ways with content, it's beginning to deal in specialized ways
> > with
> > > with various types of content.
>
> > > You can then refactor your application and shift the specialized methods
> > > into classes that extend Content Service, let's call them TextService,
> > > ImageService and FlashService. Then you have the following components:
>
> > > <cfcomponent displayname="ContentService">
> > > <cffunction name="ProcessAllTypesOfContent">
> > > </cffunction>
> > > </cfcomponent>
>
> > > <cfcomponent displayname="TextService" extends="ContentService">
> > > <cffunction name="ProcessText">
> > > </cffunction>
> > > </cfcomponent>
>
> > > <cfcomponent displayname="ImageService" extends="ContentService">
> > > <cffunction name="ProcessImage">
> > > </cffunction>
> > > </cfcomponent>
>
> > > <cfcomponent displayname="FlashService" extends="ContentService">
> > > <cffunction name="ProcessFlash">
> > > </cffunction>
> > > </cfcomponent>
>
> > > How your application would work now is that instead of instantiating
> > > ContentService to process content, you'd instantiate the specialized
> > class
> > > instead, let's say ImageService. The extents attribute on ImageService
> > makes
> > > the functions in ContentService available in ImageService. So in our
> > simple
> > > example, you'd call imageService.ProcessImage() method first, and then
> > the
> > > imageService.ProcessAllTypesOfContent() method to finish the job, all
> > from
> > > ImageService. The variables scope within ImageService would be available
> > to
> > > the ContentService's methods.
>
> > > That's all that inheritance does.
>
> > > The term "inheritance" for someone new to this can seem like it
> > > *should*mean that the parent passes on its knowledge and wealth to the
> > > child, but
> > > that ain't how it works. The child can use the parent's knowledge, but
> > > doesn't get its instance data.
>
> > > So you always instantiate the "child" object, the one with the extends
> > > attribute, to get the job done. The "parent" doesn't know a thing about
> > the
> > > "child". If you instantiate the parent object, it cannot use the child's
> > > methods or instance data, and in fact has no awareness that it even
> > *has* a
> > > child.
>
> > > If you are one of those persons who wish that their father took a more
> > > active role in your life and tend to design your applications to try and
> > > make up for it, then here is what you must do ;-)
>
> > > <cfcomponent displayname="Father" extends="PaternalLine">
>
> > > <cffunction name="CreateChild">
> > > <cfset var Child = CreateObject("component", Child).init(this)
> > />
> > > <cfreturn Child />
> > > </cffunction>
>
> > > <cffunction name="UseTheCar">
> > > </cffunction>
>
> > > <cffunction name="UseCreditCard">
> > > </cffunction>
>
> > > </cfcomponent>
>
> > > <cfcomponent displayname="Child">
> > > <cffunction name="init">
> > > <cfargument name="Father" required="yes" type="PaternalLine" />
> > > <cfset variables.Father = arguments.Father />
> > > <cfreturn this />
> > > </cffunction>
>
> > > <cffunction name="DriveCar">
> > > <cfreturn variables.Father.UseTheCar() />
> > > </cffunction>
>
> > > <cffunction name="BuyNewMac">
> > > <cfreturn variables.Father.UseCreditCard() />
> > > </cffunction>
>
> > > </cfcomponent>
>
> > > In the above example, when the Father creates the Child, notice that we
> > have
> > > passed "this" into the init() method of the Child, which in effect
> > passes
> > > all of the Father's knowledge and instance data into the child. It's
> > still
> > > encapsulated within Father, but the Child can make use of it by calling
> > > Father and saying, "Dad, can I have the car keys? I want to go downtown
> > and
> > > pick up that new MacBook Pro you promised me!"
>
> > > In our example above, notice also that Father extends an object called
> > > PaternalLine. Notice also that the init() method in Child only accepts
> > an
> > > object with the type "PaternalLine" as a Father. In this case, Father
> > has *
> > > inherited* the type PaternalLine, and what this arrangement allows is
> > that
> > > the Child can also borrow the Uncle's car and use his credit card. His
> > Uncle
> > > can stand in as his Father, because his Uncle also extends the
> > PaternalLine.
> > > The term inheritance refers originally to this mechanism of *type
> > > inheritance*.
>
> > > <cfcomponent displayname="Uncle" extends="PaternalLine">
>
> > > <cffunction name="CreateNephew">
> > > <cfset var Child = CreateObject("component", Child).init(this)
> > />
> > > <cfreturn Child />
> > > </cffunction>
>
> > > <cffunction name="UseTheCar">
> > > </cffunction>
>
> > > <cffunction name="UseCreditCard">
> > > </cffunction>
>
> > > </cfcomponent>
>
> > > In languages that use strict typing such as Java, type inheritance is
> > very
> > > important. It allows you to program your app so that the Child can go to
> > > either his Father or Uncle to use the car, for instance. ColdFusion,
> > because
> > > it's not strictly typed, doesn't need the mechanism of inheritance to
> > > provide this flexibility. You can just use type="any". So in ColdFusion,
> > > unless you're traveling the strictly typed road to ensure that the
> > Children
> > > in your application only ask family members to use the car for instance,
> > > inheritance is much less important than it seems to be from reading
> > pattern
> > > books and hanging out with people who learned object orientation using a
> > > strictly typed language.
>
> > > I hope my example is clear enough ... and doesn't have any glaring
> > flaws.
>
> > > Nando
>
> > > On Thu, May 1, 2008 at 9:52 PM, Alan Livie <[EMAIL PROTECTED]
>
> > > wrote:
>
> > > > I'll say again I'm no expert but I'm not sure it's a good hierarchy
> > you're
> > > > embarking on (but its hard to tell with no details) and think your
> > > > ContentService should probably have an association to an ImageService
> > > > instead.
> > > > Then your contentService would just use <cfreturn
> > > > variables.ImageService.getImageByGallery() />
> > > > This also means you can use your imageService in other services using
> > the
> > > > same association.
>
> > > > Although the sentence 'an image service IS-A content service' sounds
> > > > correct in the real world it doesn't mean it works at a design level.
> > If
> > > > your contentService is full of methods that your ImageService can use
> > then
> > > > perhaps it is a candidate for a parent / child relationship.
> > > > If ImageService would only ever use one or two of ContntService's
> > methods
> > > > then it definately IS NOT a good candidate for a subclass.
>
> > > > And thinking along the lines of parents accessing methods in a
> > subclass I
> > > > don't think helps either. A good way that inheritance hierarchies
> > evolve is
> > > > when you have a class then you realise you need something similar but
> > > > slightly different. Then you realise that some methods in both classes
> > can
> > > > be shared. Then you refactor by creating a parent class, copying the
> > dupe
> > > > methods up into it and taking the dupes out of the child classes. Add
> > an
> > > > extends="path to parent" and you've refactored. And you'll want to
> > unit test
> > > > this all the way of course :-)
>
> > > > Hope this helps and I'm sure some will disagree with me!
> > > > ________________________________________
> > > > From: [email protected] [EMAIL PROTECTED] On Behalf Of
> > > > [EMAIL PROTECTED] [EMAIL PROTECTED]
> > > > Sent: 01 May 2008 18:27
> > > > To: CFCDev
> > > > Subject: [CFCDEV] accessing sub-class methods
>
> > > > I need to know if I can access the methods in a child object from its
> > > > parent class and if so, how I might do that.
>
> > > > I
>
> ...
>
> read more ยป
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
