You wouldn't need super-class checking if you're using the built-in cf
"extends" keyword because you're forcing the contract at compile time
instead of at runtime.
Adding the Implements keyword into the component name is still every bit as
programmatic as using roles because it is functionality that doesn't mean
anything without the user-defined instanceOf function. In fact, we're
really just arguing sematics here - our versions do exactly the same thing.
Both of our versions rely on a bunch of strings which are not enforced by
the underlying language, and we're both just searching through a list of
strings for the one that we're looking for. You just declare yours in the
function metadata, while I declare them in the init :) It's really a matter
of preference.
As far as code reuse is concerned, you only need to have the three methods
(getRoles, addRole, and hasRole) in the base component, so it's only in one
place. There's no need to add it to each derived class. And it's very
simple code at that:
<cfcomponent displayname="Vehicle">
<cfset variables.Roles = StructNew()>
<cffunction name="getRoles" returntype="struct" hint="Retrieves the current
component's roles." access="public">
<cfreturn StructCopy(variables.Roles)/>
</cffunction>
<cffunction name="addRole" returntype="void" hint="Adds to current
component's roles." access="package">
<cfargument name="roleName" type="string" required="true" hint="The
name of the role to add."/>
<cfset StructInsert(variables.Roles, arguments.roleName, "", true)>
</cffunction>
<cffunction name="hasRole" returntype="boolean" hint="Adds to current
component's roles." access="public">
<cfargument name="roleName" type="string" required="true" hint="The
name of the role to add."/>
<cfreturn StructKeyExists(variables.Roles, arguments.roleName)/>
</cffunction>
</cfcomponent>
In the derived classes, it's even easier - all you need to do is add one
line in the init or pseudo-constructor area.
<cfcomponent extends="Vehicle" displayname="Truck">
<cfset this.addRole("Truck")>
</cfcomponent>
It's also noteworthy to add that the final end-user's calling code cannot
modify the roles that the component has using this method, whereas it can
using the GetMetaData approach. Anyway, we're both accomplishing the same
thing - it's really a matter of preference until CF finally adds interfaces
:)
Cheers,
Roland
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Barney Boisvert
Sent: Wednesday, April 06, 2005 5:39 PM
To: [email protected]
Subject: Re: [CFCDev] Question on class / subclass
Overkill? Because it's more flexible, or because it's less code?
Here's a reimplemented instanceOf method (the only change is the new
predicate on line 9). Definitely simpler than adding three new
methods to your classes, and then adding more code to your init method
to use them. Especially since you'll probably need the instanceOf
method anyway for doing superclass checking.
<cffunction name="instanceOf" access="public" output="false"
returntype="boolean"
hint="I return whether this object is an instance of the specified
type">
<cfargument name="type" type="string" required="true" />
<cfset var md = getMetaData() />
<cfset var curr = md />
<cfif NOT structKeyExists(md, "instanceOf_" & type)>
<cfset md["instanceOf_" & type] = false />
<cfloop condition="true">
<cfif curr.name EQ type OR ( structKeyExists(curr,
"implements")
AND listFindNoCase(curr.implements, type) GT 0 )>
<cfset md["instanceOf_" & type] = true />
<cfbreak />
</cfif>
<cfif NOT structKeyExists(curr, "extends")>
<cfbreak />
</cfif>
<cfset curr = curr.extends />
</cfloop>
</cfif>
<cfreturn md["instanceOf_" & type] />
</cffunction>
On Apr 6, 2005 2:13 PM, Roland Collins <[EMAIL PROTECTED]> wrote:
> Right, but I think it's overkill in this case :)
--
Barney Boisvert
[EMAIL PROTECTED]
360.319.6145
http://www.barneyb.com/
Got Gmail? I have 50 invites.
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject of the
email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject of the
email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
