- see footer for list info -<
As to the reasons for using the 'this' scope being bad practice I've
just figured how to put it (though it's hard to put in words). As I said
before, it is only bad practice in terms of writing Object Oriented
components, but afterall, that is what they are for.
Taking your example, lets say you are an outside developer using the
object and you want that query that the method populates. If the query
is stored as a property in the 'this' scope, you will need to open up
the component and view its code to see the property name, where it is
set, etc in order to know how to get at it.
If the query is returned by a method, all you need to know is the method
definition (in the case of CFCs, this can be automatically generated and
viewed using a component browser, download my static CFC documenter here
<http://www.greenhouse-design.co.uk/downloads/greenDoc.zip>).
This is a rough description of encapsulation: the outside coder can only
get and set data through the interface that the object creator allows.
The outside coder just needs documentation of the interface (i.e. the
methods) and he is set to go. The outside coder should never have to
look into the code. With this in mind, you should always set the 'hint'
attributes of CFFUNCTIONs, CFARGUMENTs and CFCOMPONENTs with useful
documentation.
By using the 'this' scope for component properties, you bypass the whole
idea of the object interface and the object loses its encapsulation.
This is why it is 'bad' practice. It may sound like a lot of hassle, but
once in the swing of writing encapsulated objects you find programming
them far more enjoyable and manageable.
Dominic
dominic watson wrote:
- see footer for list info -<
Using the this scope is 'bad' practice only in terms of O-O. Have a
look at some decent descriptions of O-O, and in particular
encapsulation Heres one that relates to java (which implements O-O
very well):
http://javaboutique.internet.com/articles/ITJ/part02/index.html
In other languages, the problem of returning multiple values is dealt
with in ways which CFCs cant handle (pointers). I would think the most
straight forward way to do it in CF is to return a STRUCT of all the
different return values. I think this is a more elegant solution as
there is one less line of code:
<cfset st_result = myObject.myMethod("argument")>
<cffif st_result.b_success>
<cfloop query="st_result.q_records">
<!--- etc. --->
</cfloop>
</cfif>
In the above example, the struct return contains two values, a success
or failure flag and the query.
In my opinion, objects and cfcs should be written so that the code
that uses them uses as little and as readable code as possible. The
code inside the objects can be as complex as you like as long as the
/interface/ that uses them is clean. The extra cfset line that
accesses the produced query seems a little ambiguous to me and would
be harder to document than a method that returns a structure that
contains the query and the other return variable.
My tuppence worth
Dom
Gary F wrote:
- see footer for list info -<
I posted a similar message on Ray Camden's Ask a Jedi blog but it
created
more questions than answers. I need to return at least 2 complex objects
(queries) from a CFC. The CFRETURN function only lets you return a
single
object/variable so I started using the THIS scope.
Example: from within the CFC
<CFSET this.myquery=myquery>
Now myquery is exposed to the parent page so I can grab it like so:
<!--- use createobject to initiate the cfc --->
<CFSET objCFC=CreateObject("component","myCFC")>
<!--- collect a varible that CFReturn would usually return from a cfc
--->
<CFSET getReturnedData=objCFC.myFunction("optional arguments go here")>
<!--- get the var/object that was explosed using the This scope --->
<CFSET myquery=objCFC.myquery>
I found this is the quickest and most effecient way to return multiple
vars/objects from CFCs without storing them in arrays or structures
which
seems like a waste of code when This works with total simplicity.
Someone
told me using the This scope is bad practice but failed to give a
reason. I
honestly don't see what's wrong with this, but I'd like to hear the
thoughts
of experienced CFC users? (I've only been using CFCs for a few months).
Thanks,
Gary.
_______________________________________________
For details on ALL mailing lists and for joining or leaving lists, go
to http://list.cfdeveloper.co.uk/mailman/listinfo
--
CFDeveloper Sponsors:-
- Hosting provided by www.cfmxhosting.co.uk -<
- Forum provided by www.fusetalk.com -<
- DHTML Menus provided by www.APYCOM.com -<
- Lists hosted by www.Gradwell.com -<
- CFdeveloper is run by Russ Michaels, feel free to volunteer your
help -<
_______________________________________________
For details on ALL mailing lists and for joining or leaving lists, go
to http://list.cfdeveloper.co.uk/mailman/listinfo
--
CFDeveloper Sponsors:-
- Hosting provided by www.cfmxhosting.co.uk -<
- Forum provided by www.fusetalk.com -<
- DHTML Menus provided by www.APYCOM.com -<
- Lists hosted by www.Gradwell.com -<
- CFdeveloper is run by Russ Michaels, feel free to volunteer your
help -<
_______________________________________________
For details on ALL mailing lists and for joining or leaving lists, go to
http://list.cfdeveloper.co.uk/mailman/listinfo
--
CFDeveloper Sponsors:-
- Hosting provided by www.cfmxhosting.co.uk -<
- Forum provided by www.fusetalk.com -<
- DHTML Menus provided by www.APYCOM.com -<
- Lists hosted by www.Gradwell.com -<
- CFdeveloper is run by Russ Michaels, feel free to volunteer your help -<
