CFC's

"Don't talk to strangers" may sound like the advice your mother used to give you as a child, but as is so often the case, mother knows best. As we'll soon see, "don't talk to strangers" or "only talk to your friends" is advice that can apply to programming as well. In programming terms, this general concept is known as the Law of Demeter, and it's a great programming practice that facilitates a reduction in coupling between objects in object-oriented applications.

Before you turn to the next article and dismiss this as applicable to OO programming but having no relevance to your procedural Fusebox application, read on as you'll see that the benefits of the Law of Demeter can easily be gained in any application that uses ColdFusion components (CFCs). By applying the Law of Demeter, you can reduce coupling between your CFCs and make your application more flexible and easy to maintain.

First let's investigate the concept of coupling. Coupling is the degree to which one object is dependent upon another or, in the case of ColdFusion, the degree to which one CFC is dependent upon another CFC. For example, if CFC A is used by CFCs B and C and the CFCs are tightly coupled, a change to CFC A will also likely impact CFCs B and C. Minimizing coupling between CFCs is an important goal as you develop your applications.

Have you ever worked on an application in which you have changed something that appears to be quite a small, isolated part of the system, but changes to this seemingly isolated part result in the application grinding to a halt? Perhaps that's an extreme example, but you don't want to make a change to a ColdFusion component in an application and have it all come crashing down because of the huge amount of dependencies between that component and other components within the application.

Systems that have low coupling reduce the impact of changes, thus making them easier to maintain. We all like things to be easier to maintain, right?

With all this talk of coupling, you may be getting the impression that any coupling whatsoever is a bad thing to have in your application. A key point to remember, however, is that a small amount of coupling is necessary in order for your application to do anything. It is unnecessary coupling that we should strive to avoid. In addition, coupling to stable, well-designed components such as the components in the ColdFusion MX 7 Admin API is generally safe as these are unlikely to change significantly in a way that will break backward compatibility.

As you build CFCs and attempt to avoid unnecessary coupling, it's helpful to think of each CFC as exposing an API to other components in the system. By exposing a public API, each CFC can hide its inner workings from other components so that outside components need only know how to communicate with the CFC, but they don't need to know any of the details related to how the CFC performs its functions.

In ColdFusion, components can be coupled in one of the following ways:

• If CFC X calls a function on CFC Y, component X is said to be coupled to component Y.
• If CFC X contains a variable (either in a variables scope or locally inside a function) that is a reference to CFC Y, component X is said to be coupled to component Y.
• If CFC X extends CFC Y, component X is said to be coupled to component Y.
• If CFC X receives an instance of CFC Y as an argument to one of its functions or an instance of CFC Y is returned from a function called on another CFC, then...

Well, you're probably starting to get the picture. Recognizing coupling and avoiding unnecessary coupling is an important skill that you'll want to develop as you build your applications.

The Law of Demeter
The Law of Demeter was first defined by Ian Holland while working on The Demeter project at Northeastern University in 1987. In brief, the Law of Demeter states that an object should only call methods that:

• Belong to itself (i.e., its own methods)
• Are on objects passed in as a parameter
• Are on objects created by the object

A full summary of the Law of Demeter can be found at www.cmcrossroads.com/bradapp/docs/demeter-intro.html. Translating this to ColdFusion, this means your component should only call its own functions, functions of components it contains, or functions of components passed in to its own functions. An easier way to remember this is basically a CFC should not call functions on components that are returned from other CFCs. For example, the following violates the Law of Demeter:

<cfset myPostalCode = person.getAddress().getPostCode() />

In the following example, we have a Person CFC that contains an address CFC held internally in the variables scope with a function named getPostCode, and getPostCode returns a postal code. To retrieve the person's postal code we may write something along the lines of this:

<cfset me = createObject("component","person") />
<cfset postcode = me.getAddress().getPostCode() />

Or maybe the following, which is really just a variation of the code above:

<cfset me = createObject("component","person") />
<cfset myHouse = me.getAddress() />
<cfset postcode = myHouse.getPostCode() />