No! Don't abandon me (and others) now! As I'm sure you well know from your experience with trying to understand all this, that it's the composite of many attempts to explain / understand that finally bring you to the point where the light comes on.
I understood parts of what you were saying...didn't fully comprehend beans (still don't completely...I think that only comes with experience)...and didn't understand everything that Isaac had to say. Trying to grasp something new and complex is like trying to pick up an ice cube you dropped on the floor...it's slippery... and sometimes you have to attempt several times to grasp it, but eventually you do. Just watch a baby try to pick up an ice cube...then you get the picture of what we're going through. None of us will ever know just what part our contributions play in the understanding of others...so please don't quit on me! If I didn't have your explanation to shift my thinking correctly, further explanation by Isaac would have been futile! But even now, the job's definitely not finished...I just managed to grasp one ice cube...but there's still a whole bucket load all over the floor! ;o) Thanks for your help! Sincerely! Rick > -----Original Message----- > From: Mike Kear [mailto:[EMAIL PROTECTED] > Sent: Monday, March 06, 2006 11:57 PM > To: CF-Talk > Subject: Re: OOP, why me? > > > I thought i had described at some length what I found the > benefits to be. I > took quite a lot of time to write it in terms i thought you'd understand. > I guess I didnt explain it as well as i thought i had. > > Oh well. I dont know how to do it any clearer. I guess you > arent going > to be "getting it" from my descriptions. I suppose I'm just not able to > communicate it to you. I'm out of this thread now. > > Good luck. > > Cheers > Mike Kear > Windsor, NSW, Australia > Certified Advanced ColdFusion Developer > AFP Webworks > http://afpwebworks.com > ColdFusion, PHP, ASP, ASP.NET hosting from AUD$15/month > > > On 3/7/06, Rick Faircloth <[EMAIL PROTECTED]> wrote: > > > > Yes...thanks, Isaac, for taking the time to > > "water it down" for me...it makes more sense now. > > > > However, the big question for me remains...what is > > the benefit for learning what almost amounts to a whole > > new language? Just reduced code? Faster execution? > > I'm sure it's faster, but how much so? > > > > This seems like a whole new programming paradigm > > to adjust to...and like all good business people, I have > > to question the ROI...how much better off will I be for > > investing more dollars and time into learning these > > new techniques? If I'm not building apps that require > > extreme capabilities and processing tons of data, and > > my apps are simple retrieve, insert, update, and delete queries > > for relatively simple apps...how much difference would > > all this make? > > > > Rick > > > > > > > -----Original Message----- > > > From: S. Isaac Dealey [mailto:[EMAIL PROTECTED] > > > Sent: Monday, March 06, 2006 10:27 PM > > > To: CF-Talk > > > Subject: RE: OOP, why me? > > > > > > > > > > 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:234406 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
