The amazing adventures of Doug Hughes


This week I was walking through some code in a code review and the question came up, why do I use the “extra” instance structure within my components. For example, in my init() function for every component, I have a line of code that looks like this:

<cfset variables.instance = structNew() />

Then, when I setup a new attribute for the component, I would store it in a variable like this:

<cfset = "bar" />

So, beyond personal habit, why do I do this? There are several reasons, some of which may be more valid in different contexts.

  1. It tends to make variables more obvious in the code so that you know what is a local variable for a function versus a global attribute for the component.
  2. You can dump this structure and see a quick snap shot of the ‘state’ of the component. While you can dump the variables scope, you will not only get the variables but also lots of function meta data which is not always desirable.
  3. For the OO purists out there, having all of the attributes contained within a structure like this makes it very simple to write the equivalent of a “copy” constructor.
  4. For components that might be extended in the future by yourself or another developer, you run the risk of variable collisions – that is variables with the same name in the base component as well as the extended component. By using a specially named structure for your instance variables, this can be prevented.

I don’t know if this was reason enough to convince my colleague, but it is reason enough for me to keep doing this in my components. Is this a wide spread best practice or am I the only one?

Comments on: "Variables.Instance" (8)

  1. michael hauxe said:

    I think this is a fairly standard practice. I’ve done this for a couple of years now, although I wouldn’t be able to say where I picked it up.


  2. I tend to keep component Global data in the variables scope such as variables.dsn, variables.dbtype. When using variables that are local to a function they are simply . As far as having all of your variables in a structure the variables scope itself is a nothing more than a structure. In the end we all basically do the same thing, I guess it is just a preference! Nice Post!


  3. Ben Nadel said:

    I did this at first because people smarter than me did it and I was learning from them. Now that I a (slightly) better understanding of OOP, I still do it and it makes sense. I don’t like that its more to type, but I think in the long run, it makes the code easier to read.


  4. Dan G. Switzer, II said:

    I do it for basically the same reason. I originally used the word “Private”, but that was adviced against. I pretty sure it was Sean Cornfield who was one of the original ones who pushed for people to use the variables.instance name.


  5. Michael Sharman said:

    Hehe, I was thinking just the same thing!

    Great point on number 4, nice one.


  6. jim collins said:

    IMHO I would give it a more descriptive name (e.g. “variables.wombat”) so it’s clear what object I’m looking at.


  7. Hussein Grant said:

    I also have to agree with jim Collins on this one. I understand using the generic term instance makes sense until you need to extend your components.
    A simple example could be Component1 extends Component2 and both uses variables.instance = structNew(). I like the idea of using the cfc name as the instance name.
    variables.myCFC = structNew()
    variables.myCFC.var1 =
    variables.myCFC.var2 =
    The chances of collisions are diminished IMHO


  8. Curious how you guys think about this pattern with talk of CF9 having implicit getters. Having everything in an instance struct might get in the way of that, yes?


Comments are closed.

Tag Cloud

%d bloggers like this: