What Is An Interface?
Interfaces in ColdFusion are something that makes most of us turn our heads sideways and give the two dollar look. Any of us who didn't come from other languages before ColdFusion probably hadn't heard of them, and since they were introduced into CF, the majority of us haven't taken the time to even understand their purpose, let alone actually use them for anything. Myself, I did take the time to know what they were for (in a ColdFusion context anyway), but even so had never found a single solitary use case for them...until recently.
For the record and to give the rest of this post context, let me share my understanding of what interfaces do for us in ColdFusion. In a nutshell, they act as validators for our CFCs. That is, by "implementing" an interface within a component (<cfcomponent implements="myInterface"....>), we are forced to adhere to rules we laid down beforehand for the functions we will write in the future, and we'll be stopped dead in our tracks if we violate any of those rules. Rules such as what arguments a function must minimally have, what the returntype of a function should be, and other criteria that interfaces allow us to specify.
My Use Case
I have recently written a small library called JBase that is a virtual relational database. Two pieces of functionality that JBase sports, which I factored out into their own components, are data formatting and validation. Now, knowing full well that I haven't anticipated every possible formatting or validation need, I created those components in such a way that they can be easily customized by the developer, AS LONG AS CERTAIN RULES ARE FOLLOWED when writing the custom functions.
I documented what those rules are very thoroughly, as well as placing them into the CFC itself as comments. But, I really wanted to be able to make CERTAIN that all customized functions followed my rules. Now this, you might be saying to yourself, is a perfect use of ColdFusion interfaces! And you would be so very right if it weren't for a couple of teeny weeny challenges, challenges that caused ColdFusion interfaces to utterly fail in this scenario.
1) CF Interfaces (as it is in all languages to the best of my knowledge) require that you EXPLICITLY indicate the name of the function you want to police - but I have no idea what my developers will name their custom functions! As long as they follow a naming convention of "format[whatever]" or "validate[whatever]", the function has a valid name according to my rules.
2) ColdFusion interfaces do not allow me to police functions that are designated as private. Why, I'm not sure, but since one of my rules is that custom functions MUST be private, this was also a fail. What to do, what to do?
Write my own interface component.
What I needed was something I could transparently apply to a component or chain of components (if one extended the other to infinity) that would inspect all of the methods and ensure those whose names matched a pre-defined pattern also adhered to other applicable rules. I called it, strangely enough, "Interface.cfc". Interface.cfc leverages a "rules" configuration array that it uses to analyze the methods, public AND private, within a component or component chain that can be n levels deep. It allows me to provide a regular expression describing function names, and when it encounters a function whose name matches the regex, it then analyzes the function based on the rules associated with that regex. Here's an example rules config array:
<cfscript>
stRules = [
{
name = "^format(?!Value).+?",
args = {
targetValue = {
type = "string",
required = "true"
}
},
access = "private",
returntype = "string"
},
{
name = "^validate(?!Value).+?",
args = {
targetValue = {
type = "string",
required = "true"
}
},
access = "private",
returntype = "boolean"
}
];
return stRules;
</cfscript>
Allow me to share a short list of Interface.cfc's highlights:
That's it! Let me show you how to use it and then what the results look like.
Picture If You Will...
Here is a rough diagram of the components that comprise the JBase relational database library. I've circled the customizable components in red:
Here is the same diagram showing interface.cfc implemented to ensure that all of the rules I lovingly outlined in the documentation are actually adhered to :) :
In this diagram, the components circled in red are those who will be validated by Interface.cfc. If we had three or four or n components in the inheritance chain, ALL of them would be subject to Interface.CFC's scrutiny. (note: the level at which Interface.CFC's functionality is triggered does allow one to control "how high" up the chain validation will crawl. The level at which "validateInterface()" is executed is where validation begins to cascade downward. Typically, you will execute validateInterface() at the topmost level component in the chain.)
To use Interface.CFC, follow these simple steps:
1. Create the rules array within the getRules method of Interface.CFC;
2. Make the most base component in the chain (or the component being validated, if there's only one) extend Interface.CFC (<component extends="Interface"....>")
3. Execute the "validateInterface()" method in the pseudo-constructor area of the topmost component that is to be validated
liks so:
<cfset validateInterface() />
<cffunction name="init" ....</cffunction>
....
</cfcomponent>
For demonstration purposes, I have chained together (via the "extends" attribute) three components with the most base of them extending Interface.CFC. My rules are defined as in the rules example above. I purposefully coded in several errors. When I attempt to instantiate the topmost component, here is a screenshot of the results:
That's it! I'm extremely pleased with the results.
You can grab Interface.cfc here. Get Interface.cfc from Github at: git://github.com/dougboude/interface.git View the awesome API documentation here.
And Boyan Kostadinov (@boyank), my .NET evangelist buddy, time to eat a little crow pie my friend. I don't UNDERSTAND interfaces??? Wrong, my man. Dead wrong. Contrary to the beliefs that keep some programmers of other languages thinking highly of themselves, this stuff just ain't all that challenging to comprehend once you weed through all the highfalutin lingo, acronyms, jargon, and fluff. Literally, I can teach this stuff to my 4 year old (and have!). ;) Love you buddy.
You are not logged in, so your subscription status for this entry is unknown. You can login or register here.
"follow a naming convention of "format[whatever]" or "validate[whatever]", the function has a valid name" Instead, you could have 'format' and 'validate' interface, which defines a public function called 'justDoIt()' ? If the 'whatever' is important, then the interface should define public get/set pairs for it.
PS foo+bar@domain.com is a perfectly valid email address, but your page doesn't allow it :-)
We didn't really run into the same needs that you did because the only thing that we wanted to enforce were the public methods because those are the methods that the system ends up "interfacing" with.
Anyway, just thought a use case might give some insights.