> Oh, man, Isaac...you just set my head spinning...(I think
> I like my simple, single programmer, 4.5.2 world...)
> I think I'll just become an athiest when it comes to
> anything
> beyond 4.5.2...(it doesn't exist except on the list...it
> doesn't
> exist except on the list...) ;o)
> I purposefully quoted everything you just said....
> aaaayyyyy!
> Rick
In retrospect on rereading that last message I sent, I can see why you
might not have found it particularly helpful. :) I did use a fair
amount of jargon in there... and I started the whole thing off with
specifics regarding cfinvoke and CreateObject() that were wholly
unnecessary to define terms. :)
Let me start over briefly with something a little simpler (and an
analogy that will probably speak to the experience you already have):
Take your database. It has tables, tables have columns. The table
itself doesn't represent an object in the real world, although
individual records in that table might. So you can consider the
metadata of the table (the number, names and data types of its
columns) as being very roughly analogous to a "class". People
responsible for creating OO terms were very deliberate about choosing
that term "class" for its meaning as a "type" of object. A "class"
therefore simply describes a particular type of object in a manner
again very roughly analogous to the way your database table describes
the records contained in it.
Now each object can have "instance data", and this is again roughly
analogous to your database, although in this case it's analogous to
the data in the table (rather than to the definition or structure of
the table). Once you have an object, the same as when you have a
table, you can typically put whatever "instance data" you want in that
object, within the restrictions defined by the class, in the same way
you can put whatever data you want in a record in your database table
within the restrictions defined by the data types of its columns. So
for instance if a column is an integer, you can put any whole number
in that column (barring size limitations imposed by the database) and
the same applies with your object -- if you define a property as
"numeric" and then define a SetPropertyX(value) method with a numeric
argument, you can place any numeric value in that property which can
then be returned with the matching GetPropertyX() method.
GetPropertyX() and setPropertyX() aren't absolute necessities, they're
merely a popular way of setting and returning "instance data". These
methods, the gets and the sets collectively are known as "accessors".
Now to break away from the analogy, the Object doesn't need the
database or vice versa. You can for instance create an object and
populate all of its "instance data" with it's "set" accessors and use
it in memory without ever taking a trip to the database (which is
doable with queries but it's more difficult). And because you can
place other functions in your objects the object then is a bit more
versatile than a database table or a query simply because it has these
extra functions (where the table or a query from the table just sits
and waits for you to use it). These routines can then reference the
previously mentioned "instance data" internally without needing that
data to be respecified continually which can be helpful in reducing
the footprint of your code. To illustrate this, take a typical page
where you might have several queries related to the same single record
in your database:
(this is bad code -- unscoped variables, no cfqueryparam tags, don't
do this :)
<cfquery name="qProperty">
select * from property
where propertyid = #propertyid#
</cfquery>
<cfquery name="qBids">
select * from bids
where propertyid = #propertyid#
</cfquery>
<cfquery name="qLiens">
select * from liens
where propertyid = #propertyid#
</cfquery>
There's nothing technically wrong with this code. It does work,
however, when you consider the benefit of having an object with
"instance data", you can eliminate a lot of repetition in your code:
<cfset property =
CreateObject("component","property").init(propertyid)>
<cfset qBids = property.getBids()>
<cfset qLiens = property.getLiens()>
Note that in the first example, I had to use the propertyid variable
three times, whereas in the 2nd example I had to use it only once
(because after the property object is initialized it knows from then
on what it's propertyid is). Of course, you'll still have to write the
above queries, however, instead of having lots of cfquery tags in your
application that all reference that #propertyid# variable, any page
that needs this information can simply use these functions (or
"methods"). That way also if the logic for fetching one of those
queries changes (if you add tables or change columns for example), you
can fix it in just one place and don't have to worry about having lots
of references to it in ad-hoc queries throughout your application.
I hope that's a bit better than my first stab. :)
s. isaac dealey 434.293.6201
new epoch : isn't it time for a change?
add features without fixtures with
the onTap open source framework
http://www.fusiontap.com
http://coldfusion.sys-con.com/author/4806Dealey.htm
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:234381
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
