Daemonite: CFCs: pseudo-OO vs

Daemonite: CFCs: pseudo-OO vs "true" OO Archive


Tuesday, September 02, 2003
CFCs: pseudo-OO vs "true" OO

CFC's and custom tags are a great subsitute for "true" OO. If you consider that the vast majority of web development simply does not benefit from the differential between CFC's pseudo-OO and Java's true OO support, it seems perfectly resonable to me to build something entirely in a pattern devised using CFCs.

If you need some lower level functionality you can draw upon Java in any event. In the scope of web application development what differences do people believe are missing in CFC OO that's available in Java OO??

Posted by modius at 10:07 PM | Permalink
Trackback: http://blog.daemon.com.au/cgi-bin/dmblog/mt-tb.cgi/156

Comments

There are only two things missing that I'd like to see. One is super, which is now no longer missing (but I bring it in case people somehow missed that this was added in 6.1). The other is interfaces.

But I think the gist of your entry is right on. CFCs are _more_ than OO enough for most projects I would think. It seems like some people tend (at times) to go a bit overboard with OO. I tend to be a bit more pragmatic. I look at how much CFCs help encapsulate my code and tend to ignore how 'not' OO they are.

Posted by: Raymond Camden on September 2, 2003 11:22 PM

I would expect most people to find that Mach II - a framework based on CFCs - would certainly be OO-enough for their web application needs. http://www.mach-ii.com/

Posted by: seancorfield on September 3, 2003 12:45 AM

I would like to see constructor functions that get automatically called when the object is created. Also I would like public/private scopes on the this. variable scope.

Posted by: David Ringley on September 3, 2003 02:38 AM

On OO:
Totally agree! We need pragmatic programmers in providing a better solution NOW!

On MachII:
Great framework, great solution to Web application development and maintenance. Simply elegant!

On interface:
In a series of Design Patterns with CFC published in ColdFusion Developer's Journal, Brendan O'Hara provides a trick in "solving" the
lack of interface in cfc with cfabort. Here is partial code from his article on Iterator Pattern (Design Patterns in ColdFusion: Iterator Pattern PART 2, CFDJ, Volume: 05 Issue: 04):

<cfcomponent displayname="AbstractIterator">
...
<cffunction name="init"
access="public"
output="false"
Hint="Initializes Iterator object // always returns this">
<cfabort showerror="Error: This Method is Abstract and must be overridden">
</cffunction>
...
<cffunction name="next"
access="public"
returntype="any">
<cfabort showerror="Error: This Method is Abstract and must be overridden">
</cffunction>
...
</cfcomponent>

Posted by: Vui Lo on September 3, 2003 11:11 AM

I've done a very similar thing, but rather than cfabort, I throw a:
...

..

Personally - I prefer exceptions.

Means they can be caught ;o)

Posted by: Mark on September 3, 2003 01:29 PM

Whoops, that didn't come out - thought it was HTML
<cfthrow message="This method is virtual and cannot be called"
type="com.InterfaceMethodCalledException"
detail="To call this method, it must first be implemented.">

But you get the drift.

(P.S. your preview brings up the old template, and i get a JS error on your site - IE6.0)

Posted by: Mark on September 3, 2003 01:33 PM