CF101

Over the past few years it's gotten a lot harder to write ColdFusion code. That's not to say that CFML has changed significantly. You can still write code today that's much the same as what you wrote five years ago or longer.

However, with the introduction of CFCs in CFMX, ColdFusion started to feel like a real programming language for the first time. CFCs, as you probably know, let us encapsulate data and functionality. With this new tool in the toolbox of CF developers, many slowly started applying advanced programming concepts to their development. This caught on and things have spiraled.

Unfortunately, many CF developers come from a non-programming background. There is all this focus on object orientation, design patterns, inheritance, interfaces, polymorphism, and (insert your own buzzword here) can be quite daunting. Traditional "procedural" development is often considered to be the one true evil. It can be hard to discover where the real value lies.

Applying all this "stuff" to your development often results in longer upfront development time. In theory you'll gain it back in ease of maintenance. Unless you're a better developer than I, the reality is that your first OO attempts will turn into a spaghetti code mess. It may even be worse than many old CF spaghetti code applications, since you're adding a layer of complexity on top of the simple approach. In this article, I'm going to help you try to make sense of the buzz, and give a comparison of procedural approaches and OO approaches along the way.

Create Your First Pizza
What happens when you order a pizza? It's probably something like this:

• Customer comes into a restaurant.
• Customer places order with the waitress.
• Waitress gives order to the cook.
• The cook prepares the pizza and puts it in the oven.
• When the pizza is ready, the cook takes the pizza out of the oven and cuts it.
• The waitress picks up the pizza and delivers it to the customer.

This is a generic enough algorithm. There may be differences and complications depending on a variety of factors, but for the purposes of this article, we can assume that we're building a system to follow that algorithm.

Let's pretend that our pizza restaurant is futuristic, and all the workers are robots. It's our task to write a program that sends out instructions to the waitress robot and cook robot so that they can operate the pizza restaurant. If you were to implement this as a traditional system for processing orders, you might come up with something like this:

• Wait for new customer.
• When customer shows up, waitress gets order from customer.
• Waitress sends order to the cook.
• The cook prepares the dough, add sauce, cheese, and relevant toppings.
• The cook puts the pizza in the oven to bake.
• Wait until pizza is ready.
• Once ready, the cook takes the pizza out of the oven .
• The cook cuts the pizza cuts the pizza.
• Cook gives pizza to the waitress.
• Waitress gives pizza to the customer.
• Go back to the beginning and wait for a new customer...

This algorithm will definitely get the job done and tell our robots how to deal with the orders. For purposes of this example, we're going to assume that our system is so efficient at processing orders that we don't have to worry about waiting on multiple customers at once. Or if you don't buy that, pretend business is really bad.

Elements of the System
Based on the descriptions of the algorithm and the first programming approach, can you identify a few of the elements in this system? Here are a few of the important elements I noticed:

• Customer: The customer is the guy who wants the pizza. He doesn't do anything except provide the order to the waitress robot.
• Waitress: This is the robot that takes your order.
• Pizza: The pizza is an element of the system, with cheese, sauce, and all the various toppings, especially pepperoni.
• Cook: This is the robot that prepares and cooks your order.

These elements come into play as we explore different implementation options for this system.

The First Implementation Attempt
Back in the dark ages of CF development, you might have implemented the system like this:

<cfif IsDefined("newOrder")>
    <cf_PreparePizza orderdetails=" newOrder" returnVariable="newPizza">
    <cf_BakePizza pizza=" newPizza" returnVariable=" newPizza">
    <cf_CutPizza pizza=" newPizza" returnVariable=" newPizza">
    <cf_DeliverPizza pizza=" newPizza">
</cfif>

Our initial algorithm had a "wait until order" clause, which doesn't apply very well to CF development. So, this code assumes that every order is provided as a page-submit, and we process it on that page. Prior to CFCs, the functionality could only be encapsulated via custom tags or UDFs. This example uses custom tags for preparing the pizza, baking the pizza, cutting the pizza, and delivering the pizza.

With this approach, functionality is encapsulated into custom tags. Data isn't encapsulated. We have two data structures in our main template, newOrder and newPizza. These data structures are passed in and out of the custom tags. This is a procedural approach to the problem. We broke things up into separate chunks, and are just telling the computer the order with which to run our code. I'm going to leave the implementation details of the data structures and custom tags to your imagination. I haven't had a client ask me to control robots from a ColdFusion program yet.

Add Your Feedback

In order to post a comment you need to be registered and logged in.

Register | Log in

Please wait while we process your request...