Ben Nadel
On User Experience (UX) Design, JavaScript, ColdFusion, Node.js, Life, and Love.
I am the chief technical officer at InVision App, Inc - a prototyping and collaboration platform for designers, built by designers. I also rock out in JavaScript and ColdFusion 24x7.
Meanwhile on Twitter
Loading latest tweet...
Ben Nadel at cf.Objective() 2014 (Bloomington, MN) with:

OOPhoto - Embrace Failure Or Optimize My Domain?

By Ben Nadel on
Tags: ColdFusion

The latest OOPhoto application can be experienced here.

The latest OOPhoto code can be seen here.

After putting some code and a lot of thought out there about OOPhoto, my latest attempt at learning object oriented programming in ColdFusion, it seems that I have reached a bit of a cross roads. Do I push forward with the intent to learn strict object oriented principles? Or, do I accept the fact that ColdFusion is not the best language for pure object orientation and put CF-optimized code in place?

If I decide to try using more pure object oriented principles such as using collections of objects over queries and favoring composed objects over foreign keys, I know that my solution will not be scalable; ColdFusion simply is not there yet in terms of object instantiation speed. However, going down that road may have several benefits. For starters, I strongly feel that understanding the core principles of solution is good. Once we understand the way something works we can see how to optimize it to fit our needs. Also, if I know that this path will eventually fail, it will help free my mind from the fear of failure and perhaps allow me to make mental leaps that I would not have been able to make previously.

On the other hand, if I know that pure object orientation is a path to failure, should I just skip that and move straight into ColdFusion-optimized object orientation? After all, that's where I'm going to end up eventually. Does it seems silly to invest time learning principles that cannot be directly applied to my domain.

This is a tough decision to make and, I think it forces the even more important question:

Is the ultimate goal here to learn object oriented programming? Or is it to learn how to build the best ColdFusion applications that I can?

No doubt, when I kicked off this series, learning Object Oriented Programming, or OOP, was my primary goal; however, it was my primary goal because I believed that it would allow me to write better code. So really, although my superficial goal was learning OOP, my underlying goal was learning how to build better ColdFusion applications.


 
 
 

 
The Matrix Dojo Scene - What You Must Learn Is That These Rules Are No Different Than The Rules Of A Computer System. Some Can Be Bent. Others Can Be Broken.  
 
 
 

Now that I more clearly see my true goal, it seems obvious that the best choice is to move forward with ColdFusion-optimized object orientation. I will put aside my dreams of learning pure OOP and embrace the fact that better applications can be written using an object oriented "influence."




Reader Comments

@Christopher,

I think that would add way more overhead to the project than would be worth it. I don't much feel like learning a whole other language just learn more about object orientation.

Reply to this Comment

I was going to ask the same question before I saw you wrote it out in bold. =)

However, after thinking about it, I would say that both instances have the same answer: take the OO to the extreme.

It will help you (and others) learn OO, and it will help you write better CF code.

If the goal of the project is to write the best CF code, then probably you should optimize. But if the goal is to /learn/ to write better CF code, then you should continue on the OO path.

Do you *know* your OO solution won't be scalable? And even if you know it as fact, can you write it out anyway and then try to find another OO solution that *will be* scalable?

If we all keep refusing to use all the objects we want we're going to be like the angry monkeys:

A few monkeys were put in a room with a stepladder and a banana that could only be reached if the monkeys used the stepladder. However, when a monkey would climb upon the stepladder, all the monkeys would be doused with water. Then new monkeys were introduced and when they tried to use the stepladder, the other monkeys would get angry and beat him up. Eventually, the room contained none who had been doused with water, but the monkeys who had been beat up for using the stepladder were still refusing to allow new monkeys to get the banana.

We'll all be refusing to write better code even if CF is capable and we'll never know why - it's some throwback to an ancient tradition.

Reply to this Comment

@Sammy,

Hmm. I have to be honest that I am really torn on this. Part of me really wants to heed your advice and move forward with more of a pure OOP stand point. After all, I have never done that and it would be nice to try it. If nothing else, I really like the idea of feeling the "pain points" of a solution before I realize why other solutions are better.

I suppose the decision has not been made yet....

Reply to this Comment

The punishment should fit the crime.

Often, when we complain about the performance penalties of writing pure OO in ColdFusion, we talk about scalability issues and with overhead.

Honestly, and no offense intended, your photo viewer application will NEVER run into scalability problems. You aren't trying to supplant Flickr, right?

You wanted a simple application that you could practice OO on. By and large, instances of this application won't see any heavy load. Optimization for milliseconds really doesn't seem like the end goal here.

So go for the pure OO app. Along the way, you'll learn a lot about what works and what doesn't work. You'll get to try certain techniques that will be awesome and some that will be pure crap. Regardless of how it turns out, you probably won't miss the wasted milliseconds....

Dan Wilson

Reply to this Comment

Ben, be careful with this slippery slope:

"my underlying goal was learning how to build better ColdFusion applications."

You're implying that pure OO code yields "better CF applications" which is not necessarily true. Use the right hammer for the job.

Also, I think it is a bad idea to go forward with pure OO knowing it is the wrong path. Pretty is, is pretty does, and if there is a better way to skin the cat that will yield better results, that should always take precedence in my mind.

Reply to this Comment

Maybe I missed the part where you defined what "better" means. This whole thing, although well intentioned, is going to be difficult for you. Here is why:

1. You are working alone. Imagine doing the same project, but with a team of 50 spread around the world. You don't know the names of these people much less how their code works. Now think about development maintenance of the project. You HAVE to have things loosely coupled. You need to be able to upgrade components and not worry about the rest of the app falling apart. You need to be able to have TESTS for your objects that don't depend on other objects. OOP in general helps for different parts of the application not have to worry about other parts.

2. Your project isn't that big. Imagine a project that IS flickr. It needs MASSIVE scalability. Not you need to optimize six ways from Sunday. OOP helps you compartmentalize your thinking. Maybe one process needs to be put on a different server or cluster. Maybe you need priority queuing. Think of all the hassles of massive scalability. OOP helps you by making objects more portable and making code more separable.

3. You weren't raised on OOP. Ask someone with a one handed tennis backhand to use two. Or vice versa. It's just not how they were taught. They will resist you. Every post in this series, you can see the same theme, "I am trying this stupid two handed backhand but it's stupid and wrong and I should just give up and do my one handed. I hit better that way anyway. Is the point to learn two handed backhand or to play better tennis?"

Here is my advice.
1. Decide if you will ever work on a team of more than 15 people. If not, I wouldn't worry about it so much. Treat this like a fun exploration and NOT something so serious.

2. Stop worrying about it. Learning is good for learning sake. Maybe this series helps Adobe to build particular improvements. Document your findings, but stop fretting. It is not unlike your "women" whining. ;)

Ok, with that said, it has been fun watching you publicly struggle. I bet alot of people benefit from knowing that even a strong programmer like you struggles too.

Reply to this Comment

This is such a small project really, why not go for the pure OO, then optimize. Doing both would yield maximum benefit.

Reply to this Comment

Keep going with the OO approach. The fact is, you know how to write good Coldfusion applications, so what do you gain really by applying all the cf optimizations that you already know?

I've been pushing forward with OO in my Coldfusion projects over the past year, knowing the whole time that I could write something that runs faster using what I already know. But it is becoming much easier for me to optimize and maintain the pieces of the project now.

Struggling through the challenges and failures seems worth it to me.

Reply to this Comment

@All,

Your points are well taken. I will move forward with the pure OOP style (or at least as pure as I can figure out). Something in my gut tells me that this is the best learning experience even if I assume that something like the IBO patterns will eventually be a hugely useful tool.

Plus, with a pure OO model, I think I need less "tricks" to get things to work. We'll see.

Reply to this Comment

Ben,
I have to chime in here also and thank for you doing this development out in the open as you have. I feel your pain. I have been attacking (learning) OO Coldfusion for the last few months and have made very little progress ( in between supporting my normal procedurally coded applications ), although I have learned a lot from the various people that post frequently on these topics. I am constantly reminded of a quote from Ursula LeGuin's EarthSea books: "Infinite are the arguments of mages."

I find some reassurance in that I am not struggling alone, and I wish you the best of luck with your difficult decision. :-) I'll be watching, hoping to get inspiration from your trials.

-Andy Lynch

Reply to this Comment

@Andy,

Thanks for the support. I really hope to come out of this journey knowing some good stuff. If nothing else, it has been awesome to get such great advice from the big thinkers.

Reply to this Comment

One thing to remember about scalability here - none of the "big" sites (flickr, facebook, linked-in, etc.) scale because they are particularly well written from an OO perspective. They scale because of caching (especially) and other optimizations, most of which are not reducible to how OO their apps are.

Reply to this Comment

I heartily agree with the advice most everyone is giving here. Plough ahead with learning the principles of OO, and worry about performance and such later. In any paradigm, whether OO, functional, or declarative, there are ways to optimize if necessary.

But to be honest, I think that a lot of the difficulties Ben is facing comes from the comical way ColdFusion implemented object-oriented programming.

Instantiation takes forever. The difference between classes and objects (or between static and instance members) is far from obvious. The package / namespace system forces all sorts of workarounds. And how what the heck is a pseudo-constructor, anyway? (Yes, that was rhetorical.)

Throw into the mix CF's typical loose typing and the ability to attach functions to objects JavaScript-style, and you have something that bears only a passing resemblance to OO as we have learned to use it in other languages.

Is there a support group out there for Java developers who think that OO in CF rather awkward, ungainly, and uncomfortable? I know I'm not the only one! :)

Reply to this Comment

Post A Comment

You — Get Out Of My Dreams, Get Into My Comments
Live in the Now
Oops!
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.