OOPhoto - Embrace Failure Or Optimize My Domain?

Perhaps you should move forward with the project using another language.

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.

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

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.

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.

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

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.

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

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.

Keep going pure OO!

....
Keep going towards pure OOP, make it your bitch.

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! :)