Testing For ColdFusion Component Interface Support

Posted April 16, 2009 at 9:21 AM by Ben Nadel

Tags: ColdFusion

Reader Comments

You know it would be even better if you could have these code segments as a graphic with tab to code view. Reading through the code is tedious just for the sake of getting the concept. I do like the content of these posts and that is just an idea how to get it into minds of more developers faster when the code isn't the actual issue as in this article. It is the existance of the interface.

Of course if that arguments of an itnerface are being tested for also you can have a whole different issue. :)

@John,

I am not sure what you mean exactly? Like a UML diagram?

@Ben - Maybe I'm missing something, but I fail to see where you're implementing an interface. I see a lot of inheritance by extending Object, but no example of implents="interfacename". Am I missing it here?

Yes... but don't get so UML standardized that someone who doesn't know UML is clueless. :)

CFC: [Name] (extends : [if applicable])
Methods:
* [method 1]
* [method 2]
+ [required argument] : (data type)
~ [optional argument] : (data type)

Drilling into the rest of the code is nice when concentrating on details but it is much like unit testing. You don't need to know the internals to understand what objects are doing. You just need the internals to understand how to make that function work. :)

I forgot to add the return type. That should be there also.

CFC: [Name] (extends : [if applicable])
Methods:
* [method 1] : (returns : dataType)
* [method 2]
+ [required argument] : (data type)
~ [optional argument] : (data type)

@Andrew,

Exactly! That's the point - there is no real interface being implemented. All the method does is check to see if one object supports the method interface of another. The idea, from what I gather in Ruby, is that if they have the same methods, you simply *trust* that they can be used in the same way.

@John,

Hmm, I could play around with something like that.

@Ben - The idea of an interface is that it is a "contract" as to how the Object will function. Implementation of the interface guarantees that the contract will be adhered to in the implementing class. Assuming that if they have the same methods you can trust them to be used the same way is a dangerous approach. Assumption is the mother of all f**kups, after all.

@Andrew,

I hear you! I am not saying I necessarily would use this. But, from conversations I've had with Ruby people, apparently, this is a feature they really enjoy.

They even use this in the "20 Minute Tutorial" on the site, when checking to see if an object has the iteration method, each:

elsif @names.respond_to?("each")

Anyway, it just got me thinking is all.

Ruby doesn't even have "Interfaces", reminds me of a blog entry I read a while back:

http://danielroop.com/blog/2008/06/28/program-to-an-interface-not-an-interface/

Ben,
I am not sure why all this trouble. Why not just use CFINTERFACE?

If one uses CFInterface, then one can simple use the IsInstanceOf() method to test whether the component implements the interface. One can also use the Interface as the "type" specification for the argument passed or return type.

It seems to me that you are going through a lot more work. Is this a support for older CF versions issue?

@Thomas,

The point is not that an object has an interface contract at compile time. The point is that an object *might* support an interface at run time. An object might even support two or three interfaces at run time (something that cannot work with CFInterface).

For example:

if (
. . . . obj.SupportsInterface( "Iterator" ) AND
. . . . obj.SupportsInterface( "Renderable" )
)

I am not saying that I have the best use-cases for this, but I just thought it was an interesting concept.

Neat experiment, Ben! It is sort of a bridge between the Java interface and duck typing of languages like Python and Ruby.

With an interface, you have to explicitly define it in a separate construct/entity with a name. Any class implementing that interface must implement ALL of the methods it defines, not just the ones you need. And most importantly, an interface is treated pretty much like a type at compile time. "This method takes an instance of a class that implements Runnable, fool!"

In dynamic languages, you can pass any object to any method. A method only expects to receive an object that implements the correct set of methods, not an object of a particular class or interface. So a class only needs to implement the methods it actually needs.

This is the essence of duck typing. A method doesn't require an object to be an instance of the Duck class or implement the dozens of methods defined in the Flappable interface. It simply requires that an object have walk() and quack() methods.

The best practice in Python for this sort of duck typing is known as EAFP ("Easier to Ask for Forgiveness than Permission"):

http://en.wikipedia.org/wiki/Python_syntax_and_semantics#Exceptions

@David,

Ruby seemed nice, from the first tutorial. But, I miss semi-colons. Why oh why do people hate on semi-colons :)

The cfcexplorer that comes with CF8 have some code that checks if an object which declares as having some interface X implemented, has all the required methods.

Maybe you will be interested to take a look how Adobe tests obj against cfinterface. :)

@John

Ack! If you want to go that route just use IDL.

component extends Super {
public function method( string arg1="default", optional numeric arg2 );
}

There's nothing in there that isn't plain text for another developer.

Notation that uses *, -, +, ~, # and what is horrendously cryptic, especially if you don't follow the UML standard.

@Elliot, :) ... I appreciate you having a different opinion. Standards make great guides but poor walls.

@Ben: "The point is that an object *might* support an interface at run time. An object might even support two or three interfaces at run time (something that cannot work with CFInterface)."

I don't use interfaces, but from the docs:

A component can implement any number of interfaces. To specify multiple interfaces, use a comma-delimited list with the format interface1,interface2.

Ben,
As Matt stated, with CFInterface, one can use multiple interfaces with the implements attribute that was added in CF8 to the cfcomponent tag. I have tested this out and it works fine (e.g., in your case you would state that your component implements="monkey,car" interfaces). One can then use the IsInstanceOf("monkey") method to see if the component implements the desired interface. One can also extend CFInterfaces, like I am doing for a current project, where I implement an IDataObject interface (standard methods of List, GetByPK, Persist, IsPersisted, etc.) and extend it for specific data objects in my model (i.e., IRequestObjects), which implement all the IDataObject interface and add in additional methods, like CheckIn, CheckOut, GetWorkHistory, etc.

@Matt, @Thomas,

That is cool. I was not aware that a component could implement more than one interface.

Post A Comment

Comment Etiquette: Please do not post spam. Please keep the comments on-topic. Please do not post unrelated questions or large chunks of code. And, above all, please be nice to each other - we're trying to have a good conversation here.

Please review the following issues:

Author Name:
Author Email:
Author Website:
Comment:	Supported HTML tags for formatting: <strong>bold</strong>   <em>italic</em>   <code>code</code>
	Remember my information
	Subscribe to comments
	Send me a copy of this comment