Conversations

Informal talks on software development with Hal Helms and Steve Nelson

Topic: CFCs and Object Modeling

Steve Nelson: So, I've been thinking since our last chat.

Hal Helms: What about?

Steve Nelson: Well, all this stuff about objects is pretty new to ColdFusion programmers.

Hal Helms: Right.

Steve Nelson: I've got your book, Discovering ColdFusion Components, ordered from techspedition.com.

Hal Helms: May you live forever.

Steve Nelson: I just don't know if I really see why CFCs--why objects in general--are such great things.

Hal Helms: Fair enough.

Steve Nelson: No, it's not, bozo. You're supposed to convince me. Sheesh, read the script here!

Hal Helms: Oh. sorry. "Gee, Steve, it sure sounds like you need some help grasping how you would work with objects."

Steve Nelson: So convince me.

Hal Helms: Well, first of all, it's not like there something horribly broken about procedural programming.

Steve Nelson: The kind CF programmers are used to.

Hal Helms: Right. And for a lot of people in a lot of situations, procedural programming works just fine. A lot of excellent applications have been written without anyone knowing about objects.

Steve Nelson: So, why should anyone learn about CFCs and objects? What's the payoff?

Hal Helms: Well, for one thing, Macromedia has made it clear that CFCs are the future of ColdFusion. That means that programmers who aren't comfortable with objects risk being left behind. And in this economy, that's not a good position to put yourself in.

Steve Nelson: That's true enough. In our industry, what you need to know changes every few months. Not the language, necessarily, but how to work with a language to do more and to do it faster.

Hal Helms: Also, languages have a natural lifetime. So it's important to see where things are headed.

Steve Nelson: Sometimes, I think it's all a fad: the language of the month.

Hal Helms: Yeah, it seems that way at times. But one thing is certain: the foreseeable future of languages is all about objects. In that sense, ColdFusion is just updating itself to be stay abreast of the latest developments.

Steve Nelson: So you're saying we have to prepare ourselves.

Hal Helms: Well, it's not like the sky is falling, but yes, I think that's just prudent. But working with objects has an appeal beyond the current fad. We've had objects for forty years in various languages, but yeah--they seem to have acquired "critical mass".

Steve Nelson: But what is the appeal--beyond the fact that they're the biggest buzzword out there?

Hal Helms: As applications get more complex or as they simply grow in response to new requirements, a language that supports objects can really simplify coding.

Steve Nelson: Simplicity isn't what most people think of when they think of object oriented programming.

Hal Helms: That's too bad, because they really are simple. I don't say making the shift is always easy--often it's not, but that's because we are so used to looking at things in terms of storing data in databases and then operating on that data.

Steve Nelson: I'd say that's about 95% of CF programmers.

Hal Helms: Yes, and to move to the world of OOP--

Steve Nelson: Object oriented programming.

Hal Helms: Right. To move to that world, we have to get used to thinking of things on their own terms--not just as data in a database.

Steve Nelson: Well, see that's the kind of talk that just goes whoosh! Right over my head. If we don't think of data in a database, how do we think of things?

Hal Helms: I'd like to suggest that we spend the next few newsletters looking more at objects and how to use ColdFusion components--CFCs--to broaden our skills.

Steve Nelson: Sounds good. How do we even get started?

Hal Helms: First, let's talk a little about what objects are--what they're meant to be and do and, as I said, I think that after a while of struggling with trying to "get" objects, you'll find they're actually very natural. Now, let me ask you a question: if I say, "What is an object?" what will you answer?

Steve Nelson: I know that objects are about encapsulating data.

Hal Helms: [buzzer sound] Ah, that's our first official OO buzzword--encapsulation. What does it mean?

Steve Nelson: It means keeping stuff together that belongs together. That is, of course, a highly technical definition.

Hal Helms: Well, technical or not, it's not such a bad definition. Let's use that for our working definition: keeping stuff together that belongs together. And what is that stuff?

Steve Nelson: Ah, you're using the Socratic method of teaching by asking questions? OK, I guess "stuff" means things like users and documents and tasks and whatever makes sense for the application we're writing.

Hal Helms: Not bad, again. Notice that you've given me nouns: "users", "documents", "tasks".

Steve Nelson: That's bad?

Hal Helms: That's good. Because OOP is first about identifying the things--the objects--that make up the model world we're creating.

Steve Nelson: What model world? You mean like these neat action figures from Lord of the Rings I've got here? Here, you be Aragorn. I'll be Legolas. "What kind of things be these objects?"

Hal Helms: Err...not exactly that kind of model. When you create a relational database together for a project, what are you trying to do?

Steve Nelson: I'm trying to store information that I'll need later.

Hal Helms: What kind of information? How do you decide what you need to store?

Steve Nelson: Well, it depends on the project. If I'm doing an inventory application, I need to store how many of a particular item is on hand. I need to know who the suppliers are, maybe the lead time for items--stuff like that.

Hal Helms: Good example. Another way of saying all that is that you're making a model--a scale model--of the real world. The real world is a jumble of stuff--too much stuff. Someone has to make sense of it--to categorize things, to create hierarchies and relationships between different parts of the world.

Steve Nelson: Why call it a scale model, though?

Hal Helms: Because we're only taking a little portion of the real world and declaring that to be important. We create scale models because they're easier to manage and manipulate than their real-world counterparts.

Steve Nelson: I just watched Patton again the other night. I was struck by the fact that the generals on both sides were moving little toy soldiers around on a map to indicate troops. The whole thing was like a game.

Hal Helms: That's exactly right, Steve. The little toy soldiers were scale models of real-world troops. The map is a scale model of a real-world country. If the generals couldn't use scale models, their ability to create strategies would be greatly diminished. Now, that might actually be a good thing...

Steve Nelson: Right.

Hal Helms: For instance, in this inventory application you talked about, who enters the new product information?

Steve Nelson: An inventory clerk, I would think.

Hal Helms: Is that important?

Steve Nelson: Yes, sure it is.

Hal Helms: OK, what about the inventory clerk's name? Is that important?

Steve Nelson: Um...maybe. Not completely sure about that.

Hal Helms: How about the fact that the inventory clerk is left-handed?

Steve Nelson: No, of course not.

Hal Helms: Or that the chair the inventory clerk sits in used to belong to the operations manager?

Steve Nelson: Definitely not. What's your point?

Hal Helms: My point is that there are an infinite number of "facts" that could be stored. But you just told me you don't care about two or three of the four I brought up. So, you're sifting through the things in the real world to decide what to keep in your scale model. How do you decide what to keep and what to discard?

Steve Nelson: I just keep the important stuff! (That's a joke.) No, I try to determine what things in the real world need "scale model" representations. And that decision is based on what people want to do with the information.

Hal Helms: See that? A natural born object modeler. You ought to raise your rates!

Steve Nelson: But I'm doing this so that I can know how to build the tables and relationships for my database.

Hal Helms: Let's say that we have a magical production environment in which the machine our application runs on will never crash. It never needs to be shut down. The machine has an infinite amount of memory. In fact, the machine is so ultra reliable and its processing and memory capabilities are so vast that there's not even a hard drive on the machine. Sound good?

Steve Nelson: Sounds great.

Hal Helms: Then I've only got one question for you. Do you still need a database?

Steve Nelson: Wow, I...I think so, but don't ask me why exactly.

Hal Helms: I think the reason is that you're modeling the scale world as a set of entities and relationships--the E/R diagram. That's providing structure to your scale model, creating an order into which things like "products" and "suppliers" fit in.

Steve Nelson: I think you're right. But that's not bad.

Hal Helms: Not at all. You're creating a data model. But your model is heavily influenced by the particular way your database stores information.

Steve Nelson: True. I'm fitting it into the constraints of a relational database with normalized data.

Hal Helms: You're actually translating it into a form that your relational database can deal with.

Steve Nelson: Like translating a word from one language to another.

Hal Helms: Exactly. You're translating real-world objects into tables and views.

Steve Nelson: I see that, yes.

Hal Helms: And OOP is just another scale model that you translate those real-world objects into. But because it doesn’t have the same demands that you "flatten" every real-world object into a table with columns and rows and then normalize those, an object model (as opposed to a data model) can be more natural, more powerful, and more flexible.

Steve Nelson: Wow, you did convince me, you silver-tongued devil!

Hal Helms: Not me. You did it all yourself. Like I said, you're a natural born object modeler.

Steve Nelson: I guess I am. Hey, maybe I should raise my rates!

Hal Helms: Well, before you get too carried away with your amazing abilities, I'd venture the idea that everyone is a natural born object modeler. It might be hard-wired into us humans. We think in object terms naturally. We naturally "encapsulate" things so that stuff that belongs together stays together.

Steve Nelson: Ah, cool. It all comes together. But we're out of space!

Hal Helms: So, we'll continue this next time?

Steve Nelson: Absolutely.

Computers are incorporated in modern ice cream vending machines to enhance their functionality. Ice Cream Vending machines are manufactured by many companies. Your competition will try to overcome all requests for high-tech ice cream vending machines and credit card acceptors

Hal Helms provides training on software development, including classes in "ColdFusion MX Foundations" and "Java for ColdFusion Programmers". His site is www.halhelms.com. You can reach him at hal.helms

Steve Nelson runs SecretAgents.com, a site for putting together clients and developers. If you need consulting or help on project management, you can reach Steve at m