posted under category: AZCFUG on March 30, 2011 by Nathan
Justin Scott left some comments for my book report on Object-Oriented Programming In ColdFusion, and I think the topic deserves a response. Justin writes:
I suppose I prefer to know the reasoning behind things like the "variables.instance" structure. I see it over and over again in CF OO discussions, but never a clear statement of the reason behind doing it that way, yet everyone seems to follow the pattern. I've not seen anything similar in any other OO reading about other languages, so it seems a little odd.I, too, have seen this pattern in ColdFusion Components (CFCs). I can't find its point of origin, probably this blog from 2008 by Ben Nadel, but I will try to explain the thought behind it.
To start, I'll say that this is a ColdFusion & CFML specific design pattern. I think the reason it is strictly CF is because of the way object composition works, with regards to the dynamic nature, and how public and private members relate to their objects.
The short reason to why variables.instance is a pattern at all is that it draws the segregating line between the implementation and execution of an object. The implementation is what is written into your application, but during the execution, your object receives its dynamic data that makes an object unique. It is saying "this instance of this CFC has these instance variables." The variables.instance pattern keeps all of the execution details in one place.
Other than the potential feeling of correctness, this segregation pattern has another benefit, a way to set or get the instance variables as a whole without danger of overrunning or exposing the implementation details of an object. For example, if you have a struct that comes from an HTML form or a database, you can set the object's execution details in one fell swoop. Also for debugging, I find it helpful to be able to dump the execution details without the often voluminous implementation details (sometimes dozens of functions and other objects).