Sean,
Ok maybe this example would be better for you <cfcomponent> <cfset this.Username /> <cfset this.Password /> <cfset this.Datasource /> <cffunction name="getEmployee" access="Package" returntype="query" output="false"> <cfargument name="EmployeeId" type="numeric" required="yes"> <cfset var Employee = '' /> <cftry> <cfquery name="Employee" Datasource="#this.Datasource#" Username="#this.Username#" Password="#this.password#"> </cfquery <cfcatch> </cfcatch> </cftry> <cfreturn Employee /> </cffunction> </cfcomeponent> I don't need to do encapsulation here, and again this one of many examples in our framework were I don't need to worry about it... My choice not yours, don't force anything onto me. Like I said I understand the risks and the dangers and it is all taking into consideration when I design my component. Regards Andrew Scott Technical Consultant NuSphere Pty Ltd Level 2/33 Bank Street South Melbourne, Victoria, 3205 Phone: 03 9686 0485 - Fax: 03 9699 7976 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sean Corfield Sent: Thursday, 1 July 2004 1:08 AM To: CFAussie Mailing List Subject: [cfaussie] RE: this On Wed, 30 Jun 2004 10:29:45 +1000, Andrew Scott <[EMAIL PROTECTED]> wrote: > But to plain say don't is > not right for those wanting to know. The problem is that the very rare situations where it is right are usually hard to explain. It's much safer to teach 'newbies' that public data members are a point blank 'no-no' and then when they have some experience tell them that there are one or two situations where it is sort of OK to use it... > <cfset oInput.Caption = "Test" /> > <cfset oInput.Width = 100 /> > <cfset oInput.Display() /> And I'd say this is a point blank bad use. You'd be better using get/set methods. Width in particular should be type-checked to be numeric (perhaps even range checked as well). That requires a set method (which is exactly the point of this whole exercise). > <cfcomponent> > <!--- Default values ---> > <cfset this.Width = 100 /> > <cfset this.Height = 100 /> > <cfset this.TextColor = "#FFFFFF" /> > <cfset this.BackColor = "#cccccc" /> So I can say obj.Height = "I'm not valid" and completely mess up your object... > Now in this case here I have a pile of default values that might or > might not change, so in this example why would I want to pass the > values that do not change each and every call to the display function? That has *nothing* to do with set/get methods. You'd never need to pass the values into "each and every call"... > Now I could use oInput.SetWidth(100) but again it's a choice not a > must do way of doing things? See above. I can totally mess up your object over if you use "this" scope instead of get/set... That's what encapsulation is all about. That's one of the benefits of OO - it can prevent accidental (or even intentional) abuse of your code... --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/ --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/
