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]
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
