An Architect's View

CFML, Clojure, Software Design, Frameworks and more...

An Architect's View

Entries for month: December 2005

TACFUG - January 2nd

December 29, 2005 ·

I'm just about to leave for the airport, en route to Raleigh, NC for the "First In Flight" cat show (spectator information - see you there?) and to speak at TACFUG about application frameworks. I expect I'll be offline until Tuesday afternoon (when I'll be back in the office). Happy New Year (in advance)!

Tags: coldfusion

Overloading is not OO

December 29, 2005 ·

I sometimes hear people criticize ColdFusion for "not being OO" on various grounds. One common "missing feature" touted as a reason why ColdFusion is not an object-oriented language is overloading: the ability to define multiple methods with the same name but different type signatures (i.e., taking different sets of argument types).
<cffunction name="foo" ..>
<cfargument name="arg" type="numeric" ..>
...
</cffunction>

<cffunction name="foo" ..>
<cfargument name="arg" type="string" ..>
...
</cffunction>

<cfset foo(1)>
<cfset foo("two")>
<cfset foo("3")>
I usually explain that dynamically typed languages can't support method overloading because you would have to do full overload resolution (i.e., finding the best match method) at runtime. In the example above, you might expect foo(1) to call the first foo and foo("two") to call the second foo. What of the third? Now add a second argument to each foo function (pick a type for each) and start to look at possible call candidates. Most calls quickly become ambiguous (i.e., it is not possible to pick a single "best match" because a number in ColdFusion can be treated as a string etc). So that's why ColdFusion cannot have overloading. Does that make it any less object-oriented? No, it doesn't. Go look at some of the classic OO languages and - guess what? - they don't have overloading either! Smalltalk is the grand-daddy of them all and allows operators to be defined on different types (effectively overloading the built-in operators) but does not have method overloading (again, because of the dynamic type issue). Smalltalk is most definitely an OO language. Here's some interesting background reading:
  • Why Smalltalk is more productive than Java (and the benefits can be applied to other dynamic scripting languages)
  • Comparing Objective-C to Smalltalk and C++ (quote: "Whether the usefullness of operator overloading is greater than it's problems is not agreed upon. But it is clear that it violates encapsulation and is a not an OO related feature.")
  • Comparing Smalltalk to Objective Caml (quote: "Because of this dynamic typing, ... This has the natural implication that method overloading is impossible, but through special object-oriented techniques such as double-dispatch the same functionally can be provided in a much 'cleaner' way.")
Note in particular that last quote - that the functionality of method overloading can be provided in a cleaner way through double-dispatch. More on that when I have a good example in CFML! :)

Tags: coldfusion

More on Factories

December 29, 2005 ·

A couple of days ago I talked about the differences between the abstract factory and factory method. Joe Rinehart has followed up with more about why factories help you write less code. He also outlines a situation where the abstract factory is useful and Doug Hughes mentions another situation in his comment. Both involve multiple similar implementations of subcomponents - support for multiple databases in Joe's example and support for multiple authentication systems in Doug's example. Joe also offers sample factory code (for the factory method design pattern).

Tags: coldfusion · architecture

Arf! - Column Name Caveat

December 28, 2005 ·

As I just discovered, Arf! won't work if you have columns in your tables with certain names... The Arf! ActiveRecord component defines several getters and setters - you cannot have a column named for any of those properties (because the generated code has getters and setters for those columns which then conflict with the base class methods). That means you can't have columns called: isbuilt, recordfactory, datasource, tablename, primarykey, relations, term or uilibrary. I doubt you'll trip over those but I did - I'm building a wiki sample app and had a column called... term. I renamed it to wikiterm and all is well.

Tags: coldfusion · orm

2005 - A Retrospective

December 28, 2005 ·

As in years gone by, I've gone back over my blog and written up a review of 2005 from my point of view. Enjoy!
Thanx to the folks who cast an early eye over the article for errors and omissions, especially Judith Dinowitz who offered several improvements in the flow and grammar!

Tags: coldfusion

Abstract Factory Design Pattern

December 26, 2005 ·

Someone asked today whether the abstract factory design pattern might be overkill for general ColdFusion web applications. I said, yes, we would find more applications for the factory method design pattern in our world - abstract factories are pretty complex beasts. So, what's the difference between the two? With factory method, you generally provide a key of some sort and the method yields an object of that type. We see this with hand-coded factories that we give a text string to and get back an object - the text string is either a simple key, the name of a component type or the ID of some object described elsewhere (e.g., an XML file). ChiliBeans and ColdSpring are two good examples of factory methods. With abstract factory, you usually have multiple factory implementations and each factory implementation is responsible for creating objects that are usually in a related hierarchy. We typically just say "factory" and we mean "factory method". Want to see an abstract factory in all its glory (gory?)... check out this 1996 article I wrote about building a compiler. I didn't call it an abstract factory design pattern because back then I didn't know the names of those patterns very well (the "Gang of Four" Design Patterns book appeared only two years earlier). If you're feeling masochistic and want to understand a bit more about what makes me tick, feel free to read the entire compiler writing series (six parts, written between 1994 and 1996 and published in Overload).

Tags: architecture

Objects and Persistence Talk / Code

December 25, 2005 ·

I'm pulling together my objects & persistence talk for various CFUGs and CFUNITED and, like my frameworks talk, I'll be building a small sample app in a number of variants to accompany and illustrate the talk. It's a wiki (like we need another wiki, I know!) that supports very basic CRUD operations. I've just completed the first two variants - there will be seven or eight by the time I give the talk, illustrating "traditional" ways to handle persistence as well as how the various ORM frameworks do it and some intermediate "data tier" transformations variants. If there are techniques you'd like to see illustrated or explained in the talk or its code, let me know in a comment here.

Tags: coldfusion

Technorati

December 25, 2005 ·

I'm not sure why but I never got around to adding my blog to Technorati... Nor even using Technorati to search blogs. So I just created a Technorati account and added the embed / links (bottom of the right hand column here). How many folks use Technorati? What do you think of it?

Tags: blogging

Seven Stages of Expertise

December 24, 2005 ·

I saw this linked from Hal Helms' blog but wanted to give it both a broader airing and add some commentary. Meilir Page-Jones has written about the seven stages of expertise in software engineering (and bear hunting!). Innocent, exposed, apprentice, practitioner, journeyman, master, researcher. Go read the article for what each really means (he does bear hunting first, then software engineering). Some years ago I was chatting with Scott Meyers (author of "Effective C++" etc) and he felt there are three broad classes of programmers: public, protected and private. Private programmers write operating systems and frameworks and other sorts of "black box" software. Sometimes they mentor teams of other programmers. Protected programmers understand APIs and frameworks and help drive projects (some protected programmers also write frameworks). Successful projects have at least one protected programmer mentoring the others. Public programmers build applications. They use frameworks and libraries but they don't usually understand exactly how those things work, just that they do work, and they rely on the protected (and private) programmers to help them design systems and get things working. Going back to Meilir's seven stages, the private programmers are the masters and researchers; protected programmers are the journeymen and maybe some of the practitioners; public programmers are practitioners and apprentices (and occasionally some exposed programmers). Meilir's J-curve is an important issue to consider - as folks advance from apprentice to practitioner they experience a drop in productivity as they take on all that new information and assimilate it. Meilir notes this can take between six and eighteen months and that moving on to the next stage (journeyman) can take another eighteen to thirty-six months. Don't underestimate the time this progression takes! I've encountered people who think they can just pick up a new technique (like OO) and be productive immediately - and who got quite angry with me when I suggested otherwise. As Meilir says, in general the shortest time from a seminar to full productivity with that technique is about two years. Most of all I want you to read the article and take heart that learning new techniques really does take time. It doesn't mean you're stupid just because you don't get OO in a few weeks - you should expect proficiency to take a good while. My early OO efforts were pretty horrible, looking back... (hmm, looking back to 1992 when I started to learn OO!). Also remember that the seven stages apply to each individual technique or skill so there is always more to learn as new techniques appear and new skill opportunities are offered.

Tags: programming

Rob Brooks-Bilson on the Best of 2005

December 23, 2005 ·

The best blog postings, that is. Rob's top ten covers quite a variety of posts from a number of bloggers. Most of the posts deal with OO / design patterns in some form or another but there's also Steven Erat's excellent post on how ColdFusion processes requests. Some good reading there, and it's nice to review some of the older posts again.

Tags: coldfusion