To Type or Not to Type - The Big Question

I thought i'd follow up on the post about polymorphism with a more down to earth post about typing in ColdFusion, because 90% of that post turned out to be about typing anyway. And believe it or not, there's still more to say on the topic.

Once you get to know your way around a little, one of the most confusing things for a CF developer who is new to OO is whether or not to explicitly type your arguments and return types, and indeed, how to deal with problems that arise if you do. Because when problems arise, you start to think "Why am i explicitly typing these CFCs? What good is it?" - and the To Type or Not to Type question is revisited again.

Those coming into OO in CF from other strictly typed languages will probably tend to advise us to type our CFCs, because, well, that's what they are used to doing, and they know the territory and its advantages. They also might tend to work on more complex applications and in teams, because they are highly experienced. And typing has advantages in complex applications and when working in teams.

Those writing about OO already in the CF world are also almost certainly experienced in OO from other languages. So you're likely to see examples that employ explicit typing in those writings. And as a newbie, you'll probably just follow along there in an effort to do it right. But explicitly typing your CFCs needs skill and experience to get right. So us CF/OO newbies, who are not used to needing to strictly type our variables, run into some brick walls almost immediately.

What we need to understand, i believe, is that explicitly typing your CFCs has it's advantages and disadvantages. The same is true for loosely typing your CFCs. Let's see if we can get an overview, so we can make a more informed choice about typing from the very beginning.

Advantages of Explicitly Typing your CFCs

* If you're working in a team or will be providing an API that other developers will use, it will probably be a lot easier for others to understand your code if you type your CFCs. (You could also provide similar documentation in the hint attribute.)

* You gain a degree of what's called "type safety" in your code, but this a little more theoretical than practical in CF.

In a strongly typed language that's precompiled like Java, your code won't compile if your types don't line up - for instance, if you try somewhere to pass a variable declared as a string into a class that is expecting an object of type Person. That's type safety. The code won't even run.

But in CF, the code will run, and what you'll get is a slightly different error at runtime. So if you make a mistake and don't catch it yourself, your users will be exposed to it. So in this sense, in ColdFusion, type safety works more through the fact that the expected type is documented in the method's type and returntype attributes, and the runtime error says to the developer "See, i told you so!"

* As a more personal side benefit, explicitly typing your variables may help you to feel like you know what you're doing. ;-)

Disadvantages in Explicitly Typing your CFCs

* For the newbie, if you start off explicitly typing your CFCs, it can be difficult to get your objects to play together nicely. To build an app of any complexity, you'll probably need to understand polymorphism and may need to get your head into design patterns. And that takes awhile. So your learning curve becomes much steeper, and if you're learning on your own, you may just hit a white wall or a glass ceiling and not know how to go on.

* Typing needs to be hard coded, and is server-wide, not application specific. Which can wind up to mean that your code is less portable. If you need multiple instances of an application on a single server or are building an app to be distributed and installed on other servers, you or your clients can easily run into difficulties.

Mappings might need to be set up, which may conflict with other mappings on the server. You might wind up having different versions of the same app that you want to run side by side on a single server, and then each version needs to be gone thru and the type, returntype and extends attributes will all need to be changed, and the whole thing will need to be tested to make sure it all works.

Some people have placed all their CFCs in a single directory, so they can easily "see" each other and just type them with the CFC name. If you use factories and instantiate your factories from the root of the site, you can get by. Others have tried placing their CFC's in the webroot of their site, and then when CFAS looks in the webroot first for the CFC, it finds it there.

Security conscious developers tend to want to place their CFCs outside of the webroot, so neither of those workaround is acceptable to them.

Blue Dragon has the possibility to set up Application specific mappings, which solves this problem. Hopefully CFMX8 will also implement this feature.

* It takes extra processing time, especially if the process uses a number of CFCs. This may or may not have a noticable effect.

* Error handling is a challenge for all kinds of typing, native types included.

To give a simple example that illustrates this with a native type, let's say that you have a form that asks the user to fill in their birthdate. You're going to pass the form values into a CFC when the form is submitted. You type your setter to expect a date, like so:

Knowing that one of your users may enter something in that field that ColdFusion doesn't recognize as a date, you begin to realize that you'll need to handle the "is not of type DATE" error that bounces off this function somewhere else ... where should i do that? You can't do it from within the method itself.

Should i wrap every piece of code that calls setBirthDATE() in a try - catch block and search for the error " ... is not of type DATE" and handle that? If i use this CFC in multiple places in my code, that's going to be a mess. It would be much better if all my "... is not of type ... " errors were encapsulated.

With dates, even in ColdFusion, we become concerned with type safety when we know we're going to insert a date as a date type of some sort in a database or use date functions on the date. But as you can see, simply typing a method's argument as a date doesn't make it a date! In other words, our explicitly typed method doesn't take full responsibility for a situation where we don't know the type ahead of time. The same is true with any other type besides "date", be it a native type or a CFC.

In cases where you don't know the type ahead of time and would like to handle the error, it can be a challenge to architect. You may feel like your object should be able to take responsibility for dealing with types that it rejects as being incorrect, but it won't. It will behave like a government official that you call and ask, "Can i renew my drivers license here?" and they just say No! and hang up. GovernmentOfficial doesn't take any responsibility if your request is of the wrong type.

Since you'd probably want to set up some way to encapsulate the type error and handle it in one place, you might then look for a solution to that. One way might be to process all your calls to that method thru another method that accepts any type and wraps the call to the typed method in a try catch block or other validation approach. If you're using CFCs to handle all your data, you'll eventually come to that idea. Again, this would be only for methods where you don't know the type ahead of time and it's not managed with polymorphism in some way.

Let's go back to our birthdate example and take a look at a variation that might handle a typing error more responsibly.

In this variation, we've kept setBirthDATE as before, with an argument typed to accept a date, except that we've changed the access to private so that this method can't be called from outside the CFC. And we've added setBirthDAY() as a public method that accepts any type in it's argument. setBirthDAY() checks to make sure that whatever value is passed into it is indeed a date, and if it is, it calls the setBirthDATE() method and passes that validated value into it. If it's not a date, it adds birthday as an invalid field to a list of invalid fields, the idea being that we would check if there are any invalid fields before persisting our data, and if there are, redirect to the form and display a message to the user asking them to correct the birthday field.

Now, what i like about setBirthDAY() is that it's taking responsibility. setBirthDATE() is almost unnecessary. We could easily refactor our code to look like this:

and eliminate the setBirthDATE() method.

What i'm saying here is that when you see a need to handle typing errors in your code because you're not sure what the type is going to be at runtime, typing your arguments isn't going to help you, and you may find that you're better off using type="any" and encapsulating your error handling within the method itself.

If we go back to our setDriver() example from the polymorphism post, we could consider dealing with it in a similar manner as the setBirthDAY() example. Someone brought up the problem of the Child in the comments under the post. In our example, a Child is also a Person, but shouldn't be allowed to drive the car. And indeed, in real life, a child is able to get their hands on the keys and turn them in the ignition, unlike our Dog. So it's a real-life problem this time that may need a solution in our app.

So what if we found ourselves suddenly in the position where the police knocked on the door and said, "If you don't modify your application immediately so that your child can't drive that car, you're going to jail!"

The pressure is on. There's no time to order any more books on design patterns from Amazon.com and sit up late into the night reading them, hoping to come up with some polymorphic design pattern style solution that will allow Man and Woman but not Child to drive our car, even tho' they are all Persons, without tearing our whole application apart and starting over. We don't have time for that. We need a solution, and we need it now.

Here's what i did to keep myself out of jail.

I moved all the components into a test directory on my laptop so i could easily show the police officers on our front porch how i'd solve this problem. Elisa offered then a cup of coffee and told them i'd have a solution for them in a few minutes. As she was coming back into the kitchen, she eyed me intensely and said "Hurry!" under her breath.

She just came back to the kitchen to get a few donuts for the officers out on the porch. "How's it going?", she whispers under her breath, with that edge she gets sometimes. "Going good. Gimme a few more minutes."

"They're waiting ... "

As you can see, i left everything pretty much as it was. setDriver() is still expecting a Person so we don't get no kangaroos or anything like that trying to drive the car. But ... if you take a close look at setDriver(), i added a few bits of code in there to check if the Person sitting down in the drivers seat is of type Child, and if it is, we throw an error. Check the CF documentation for getMetaData(), which is a native ColdFusion function, for more information.

So let's test this and see how it works:

Ok, great. It's working. I'm getting the error onscreen.

Whoa! You're too young to drive the car!

So i take the laptop out to the porch to show them and the officers are pretty impressed.

One looked at the other and said "That Java programmer 'cross town. Is he still in the slammer?"

"Naw, i think he got out a few weeks ago, didn't he?"

Anyway, the officers thought it was pretty damn good as it was, but one of them scratched his head under his cap, you know how they do taking the brim between their thumb and index finger, and asked, "Aren't you supposed to redirect kids to another site or something?"

"You mean like to disney.com?"

"Yeah! Right!"

"Hang on a minute"

Sitting there on the porch, i made a quick adjustment to my Application.cfc file in my test directory, tested it, and ran it for them.

"Wow! That's it! Perfect!"

When our kid sat down in the drivers seat, he got redirected to disney.com and forgot all about trying to drive the car.

Anyway, so the cops were really pleased. My wife asked them if they wanted more coffee or anything, but they stood up and said "No thank you ma'am. We'd best be on our way."

As they were starting their sqaud car, my wife looked up at me with her big dreamy eyes and said "Darling, i'm so glad you're not a Java programmer".

;-)

For anyone new to to all this, i've just been playing around here, experimenting with a few novel ideas in code. I'm not saying that any of this is certified, best practice, or even intelligent. But i did keep myself out of jail in a pinch back there, and could use the same technique to quickly adapt to new requirements in another application if my technique stood the test of scrutiny and time.

Stepping back further, i'm questioning the value of always typing the arguments and returntypes in CFCs. If i was working in a corporate environment and was asked to, i'd say "Sure, no problem." If i'm developing an app on my own, my tendency would be to type only if i saw a direct and practical need (like we do for a date that needs to be stored in the database.)

We don't type variables unless there's a clear need in CF, and i'm inclined to take the same approach with CFCs. Otherwise, a hint attribute will suffice for documentation to remind me and anyone else looking at my code that an argument is expecting a specific type of object.