The Largest Repository of ColdFusion Knowledge in The World for More Than 12 Years

ColdFusion on Ulitzer

Subscribe to ColdFusion on Ulitzer: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get ColdFusion on Ulitzer: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


CFDJ Authors: AppDynamics Blog, Michael Kopp, Tad Anderson, Bob Gourley, Jayaram Krishnaswamy

Related Topics: ColdFusion on Ulitzer

CFDJ: Article

Baking Object-Oriented Pizza with ColdFusion

Procedural programming and OO programming buzzwords

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.

More Stories By Jeffry Houser

Jeffry is a technical entrepreneur with over 10 years of making the web work for you. Lately Jeffry has been cooped up in his cave building the first in a line of easy to use interface components for Flex Developers at www.flextras.com . He has a Computer Science degree from the days before business met the Internet and owns DotComIt, an Adobe Solutions Partner specializing in Rich Internet Applications. Jeffry is an Adobe Community Expert and produces The Flex Show, a podcast that includes expert interviews and screencast tutorials. Jeffry is also co-manager of the Hartford CT Adobe User Group, author of three ColdFusion books and over 30 articles, and has spoken at various events all over the US. In his spare time he is a musician, old school adventure game aficionado, and recording engineer. He also owns a Wii. You can read his blog at www.jeffryhouser.com, check out his podcast at www.theflexshow.com or check out his company at www.dot-com-it.com.

Comments (2)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.