Heresy

I was talking with my friend, John Q, recently about Java. John came to my Java for ColdFusion Programmers class (coming to DC in March -- info below). John has a project coming up and was wondering whether to try out his newly acquired knowledge of Java or to stick with ColdFusion.

"On one hand, I think I really learned enough to tackle the project. On the other hand, maybe I should stick with ColdFusion, since it's so easy to code with," John said.

I told him, "Well, I know this is heresy, but I actually think Java is easier to write applications, once you get over the learning curve."

Maybe you're as surprised by that statement as John was. Let me qualify it, though, and try to make an argument that I'm not really smoking illicit substances. First the qualification: By "getting over the learning curve", I really mean making the mental shift to thinking in objects. The time it takes for this to occur differs for everyone. Most CFers start off with the mindset appropriate for writing ColdFusion code: an application consists of data in a database that is taken out of the database, displayed, manipulated and massaged and then sent back to the database.

As obvious as this approach seems, it's the wrong way to approach a Java application. Instead, a much better approach is to ask, "What sort of things will populate my application? What do these things know about themselves? What can they do? Who else can they communicate with?" If that seems a bit anthropomorphic, it's meant to. The best OO software developers think in terms of objects as being alive -- something that I refer to as "thinking in objects."

Determing what things will make up your application-world is called "building an object model" and I won't deny that it's hard work. One of the best pieces of advice I can offer beginning Java programmers is to, as much as possible, let your objects model the real world. At a recent Java for CFers class in Las Vegas, the class was asked to design and code a realistic Blackjack game. I gave them a ColdFusion front end; they had to design and write the Java for the back-end logic. When done, we integrated the CF front end and Java back end.

The question came about of how best to have cards that would be dealt only once. Some students thought that each card should have an isDealt boolean property but Rick Moon, one of my students, didn't agree. "If we're really trying to create a scale model of the real world, then I have to ask whether a card would know if it was dealt or not. I mean, that's outside the card's world. It should know it's value and its suit, but that's about it."

Rick was right. His solution, an elegant one, I thought, was to create a deck of cards that responded to a nextCard() message. When the deck was asked for a card, it picked one of its remaining cards at random and handed it to the requester. Then it removed that card from its deck so that it could not be played again. It was a simple, clean solution that required a minimum of code and that could be reused for any card game.

The value to "thinking in objects" is enormous. The object models we produce once we train ourselves in this skill help create robust code. When the inevitable changes occur, object models produced by object-thinking designers prove to be adept at changing without breaking.

OK, but earlier, I said "easier". Is this really true? I sure think so. Clean object models mean that each object and each method have very limited responsibilities. That makes for code that's highly reusable. Having to write less code is obviously easier. But beyond that, writing clean Java code means simply calling these methods. For example, look at this code for the dealInitial() method of the dealer:

getPlayer().addCardToHand(getDeck().nextCard());
getDealer().addCardToHand(getDeck().nextCard());
getPlayer().addCardToHand(getDeck().nextCard());
getDealer().addCardToHand(getDeck().nextCard());

if (getPlayer().getHand().isBlackjack()){
   if (getDealer().getHand().isBlackjack()){
      getPlayer().push();
      getDealer().push();
  }
  else{
      getPlayer.win(getPlayer().getBet()*2.5);
      getDealer().lose();
  }
}

When you see this syntax, fooBar(), you're looking at a method -- something an object knows how to do. For example, the method, getPlayer(), returns the Player object. You can chain methods together, so that the first line of code says:

1. get the player
2. tell the player to add a card to his hand, where the card is the one gotten by...
3. getting the deck and...
4. getting the next card from the deck

In the dealInitial() method, we get cards twice for the player and twice for the dealer. Then the dealer asks the player's hand if there is a Blackjack. If so, the dealer checks his hand. If both are Blackjacks, a push occurs. Otherwise, the player wins 2.5 times his bet and the dealer loses.

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

Is the syntax different from what we're used to with ColdFusion? Sure, it is. But the new syntax is quite easy to learn. And because Java is a compiled language, Java IDEs (including the EXCELLENT and FREE Eclipse) make building applications easier. When I type getPlayer()., the Java IDE already knows that this method will return an object of type, Player, and will present in a drop-down only those methods associated with the Player class. To CFers who must run their code to find errors, this design-time checking is enormously helpful. ColdFusion Studio and Dreamweaver have this built in for ColdFusion's tags, but with Java, the methods for the objects YOU create is instantly available as well. It's hard to overemphasize what a powerful tool this is -- and how it cuts down on run-time errors.

By the way, that dealInitial() method is the one of the longest method in the whole game. Over 90% of the methods are three lines or less. One of the reasons that Java makes building applications easier is that once a method is designed, we can forget about exactly how it works. I call nextCard() and get the next card automatically. Of course, we can do this in CF if we use <cfmodule> for everything, but Java makes it easier and more natural. What feels like unnecessary rigor at first quickly becomes a powerful support for building robust apps.

"OK," said John. "Java it is." If you'd like to accelerate your move into Java, why not join us in Washington, DC on March 3-7 for "Java for ColdFusion Programmers" class? Leverage your ColdFusion skills to get a headstart on learning object orientation with Java. Details at www.halhelms.com.