Design Patterns in ColdFusion: Creational Patterns By Brendan O'HaraWith the recent introduction of ColdFusion MX 6.1, developers continue to explore the new features andimprovements ColdFusion has to offer. What you may discover, as I have, is that we have hardly scratched the surface of what is possible with ColdFusion Components (CFCs). Introduced last year with the release ofColdFusion MX, CFCs were a radical leap forward for the language. Getting used to this new paradigm, andgetting the most out of it, will take a while even for the most seasoned CF developer. ColdFusion MX is built on top of the Java/J2EE platform; in fact MX 6.1 now includes a full version of JRun, Macromedia's Java application server. ColdFusion has the ability to directly connect to and utilize Java natively. This gives developers the tremendous power of Java i n addition to the Rapid Application Development (RAD) capabilities of ColdFusion and CFML. However, most of us aren't Java experts, and J2EE projects, although highly scalable and stable, aren't easy orfast to develop. This is especially true in comparison to ColdFusion. In addition to this new (in MX) and expanded Java interactivity, we also have a CFML extension to the language. ColdFusion Components, or CFCs, can be used in many of the same ways as Java objects. They are not pure OOP but they are pure CF. That is, after a small learning curve on creating and using CFCs in your code, the actual writing of CFCs is done completely in ColdFusion so as to make it open to the entire range of CF developers. So what are CFCs good for? Are they simply static function libraries? Are they object-light components used forFlash Remoting or Web services? Are they a replacement for custom tags? Are they objects? The answer to all ofthese questions is "Yes." They can be all of those things and so much more. If you have read a number of my previous articles you know I love CFCs and use them for just about everything. Static Methods and Function Libraries Since we are at release 6.1, I'll assume everyone has had some experience with user-defined functions, or UDFs. The script-based variety was introduced in ColdFusion 5.0. UDFs are extremely useful ways to expand the functionality of ColdFusion. UDFs are custom functions we create to eliminate repetitive coding of simple processing routines or to ensure that those routines aren't forced to live inside a custom tag as they had to before ColdFusion 5.0. In ColdFusion MX, a tagbased UDF syntax was introduced, using the <CFFUNCTION> tag, that further expanded UDFs and also makes up the basis for the writing methods inside a CFC. To use a CFC method as a static (or nonpersistent) function, use this syntax: <cfinvoke component="tax" method="getRateByState" returnvariable="taxrate" state ="PA" /> This method returns the sales tax rate for a passed-in state code. This is one approach. Another is to use the <CFOBJECT> tag to create a variable that is a reference to an entire collection of functions or a function library. To create a reference to your function library, you call <CFOBJEC T>, the same as creating any other CFC reference: <cfobject component="myTaxFunctionLibrary" name="tax"> Since this CFC instance "persists" you can access any function from your library using <CFINVOKE> as shown: <cfinvoke component="#tax#" method="getRateByState" returnvariable="taxrate" state ="PA" /> You can also call the function inline; simply reference with dot (.) syntax as in #CFC.Method(args)#. This is available because the variable "tax" references the CFC instance, which is our function library. #Tax.getRateByState("PA")# While this is the way static function libraries would be done in Java, it isn't in my opinion the best way to do it in ColdFusion. I'll explain why. In general, objects have Class data and Instance data as well as Class methods and Instance methods. Class data is the same for every instance of a CFC. Instance data is different for most or all instances of the CFC. Instance data is usually set in a constructor or initialization method often named init(). If a CFC method doesn't use any "instance data" and doesn't make any <CFQuery> database calls, it probably shouldn't be an instance method. Instance methods access instance-spec ific data for dynamic runtime processing. Class methods act exactly like UDF functions. They process dynamically, but they do so based only on passed-in arguments, since like a UDF, they have no instance data to use. In Java you are forced to create static functions within a Class because everything is an object in Java. ColdFusion, while more structural in nature, does not have that "limitation". Perhaps the best solution in ColdFusion is to treat static functions similarly to a JavaScript function library.
