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 have a contentService object that is getting fairly full of
> > > functions, many having to do with images so I was thinking of creating
> > > a sub-class of content and call it imageService. What I have is a
> > > getImageGallerys() function and a getImageByGallery function(), among
> > > others. I plan to create a function that gets a single gallery from
> > > getImageGallerys(), then uses the gallery's id to retrieve its images
> > > from getImageByGallery() returning that query to the view.
> >
> > > I guess I was thinking this function would be in the contentService
> > > object, but I suppose it should be in the imageService sub-class I
> > > will create. What are your guys thoughts on this, and can I access
> > > methods in a sub-class from a class?
> >
> > --
> >
> > Nando M. Breiter
> > The CarbonZero Project
> > CP 234
> > 6934 Bioggio
> > Switzerland
> > +41 76 303 4477
> > [EMAIL PROTECTED]
> >
>
--
Nando M. Breiter
The CarbonZero Project
CP 234
6934 Bioggio
Switzerland
+41 76 303 4477
[EMAIL PROTECTED]
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
