The Tao is like a well: used, but never used up. It's like the eternal void: filled with infinite possibilites. It's hidden, but always present.
Creating a Java program is a bit like making a movie or putting on a play. Every theatrical production needs actors (in Java these are objects), roles the actors play (classes), and scenes the actors play out (methods). In a movie or play, actors step into one of their scenes when given a cue; in a Java program, objects enter one of their methods when cued to do so by another object. The Java interpreter, which runs each Java program, is like a combination stage manager and producer---it creates the set, casts the actors, and teaches them their roles. We, as Java programmers, are like playwrights (or screenwriters) and directors put together, we specify the roles the actors will play. Our program's users are the audience.
Just as a stage manager and a producer read a play or movie script to find out what sets to create and what kinds of actors to audition, the Java interpreter reads each of the classes that we as programmers write to find out how objects of that class must behave (their role). Unlike temperamental actors, however, each Java object does exactly as its class tells it, so each object is the personification of a single role. Real actors can play many roles; Java objects are all role. A play's script usually specifies the actions of many characters in lots of different roles: butlers, tycoons, girl scouts, lone gunmen. A Java class, however, only specifies the actions of one quite specific type of character; that is, one role. So a simple Java program might be the equivalent of an extremely boring play about a butler forever polishing silverware, or a snoozer about a tennis pro playing exactly one round of a game of tennis. A complex program, however, might describe a universe of thousands of roles for its objects to play, all working together to run a sophisticated game, a nuclear power station, a national telephone service, or an orbital telescope.
|playwright and director||programmer|
|stage manager and producer||Java interpreter|
This analogy only goes so far of course: there's no way to create an actor out of thin air in a play---yet in a Java program we can create as many objects as we want. In a play, producers are the money people, stage managers help organize things, and directors are in charge of all things artistic; so while producers and stage managers have some say on casting, the director has final say. Also, unlike a play, no Java program needs a stage, lights, or scenery; nor does it need costumes, makeup, orchestras, auditions, rehearsals, stagehands, ticket sellers, primadonnas, stage fright, or tantrums.
Suppose you've been asked to create a new hotel franchise. This might make for a pretty boring play, but it's the kind of thing programmers have to do all the time---someone can make money from it. The first building of the future chain is already built and furnished, and all the parking, power, water, sewage, and electronic and communication systems have been installed. It is, however, a long way from being a hotel because a hotel is much more than a building with beds in it. Just as a building's architect must first design the building, you, as the information architect, must first design how people and machines are to move and function within it. This sounds simple but the information architecture problem is frequently quite hard because often it's as if you were asked to design the world's first hotel; usually no one has any real idea exactly what they will want the new hotel to do for them.
So what is a hotel? Or, to cast it a bit more in computer programming terms, what must a hotel be able to do for you? From the programming perspective, a hotel is a machine to support people away from home. Admittedly, it's a strange sort of machine, since some of its components are people, and faucets, and doormats, but its essence is that of a machine---something we can design, build, then allow to run on its own. From this information architecture perspective, a hotel must accept new guests, it must welcome returning guests, it must transport guests to their rooms and explain the functions the hotel supports, and it must provide for guest needs---a newspaper every morning, laundering their clothes, whatever. Assuming that you don't already have people to do all those different things you're not really choosing staff at this stage, you're deciding on roles for the future staff to play. You can hire the people who will play those roles later. Your first task, then, is to figure out all the roles that each of the people you will eventually hire as staff must play to run the hotel---you must design the hotel.
Unless you've designed a hotel before the problem is too complicated to think about as a whole, so you must break it into manageable pieces. You might divide roles into creators and maintainers; a cook would be a creator, a housemaid would be a maintainer. Or you might divide roles into guest contact and infrastructure; a valet would be guest contact, a launderer would be infrastructure. Or you might divide roles into food-related, sleep-related, transport-related, and so on. As you get further along, each design choice will have consequences---some good, some bad---but you won't know what they are until you're in too deep to change major parts of your design.
Actors and Roles
Let's say that you create roles based on when a typical guest needs the various roles to be played. Most people visiting your hotel will likely come in a car---you'll need someone to park the car, a valet. As they leave the car you could have someone welcome them and open the door, a doorman. Entering the lobby they'll need directions and perhaps instructions, a concierge. Then they'll need to check-in---a desk clerk, and so on. Although these are roles, they're eventually going to be played by some specific actor. An actor and a role are related but not the same; actors play roles, they are not themselves roles. Similarly, objects belong to classes, they aren't themselves classes. As you think up more roles you might consolidate related ones to be handled by one actor. Thus, a small hotel might have no concierge, but the desk clerk plays that role. Conversely, you might explode complicated roles into a collection of simpler ones. A large hotel might have several restaurants, each with their own maitre d', who may be so many that they require their own manager. During design, it doesn't much matter whether you can later afford to hire one person to play each role, or whether you'll need to have one person play multiple roles; what's important is to identify the functions your hotel must support.
Let's say you now have sufficiently many roles to cover the basics. If the problem is at all interesting, you've likely forgotten many things. For example, did you think about what to do if there is a fire in the elevator shaft? If a guest dies? If there's an earthquake? During design you must play out various scenarios in your head and think of which role might be most appropriate for various circumstances; if none are suitable you must invent a new role. As you think about your design and new problems occur to you, you might decide to do nothing (the equivalent of printing "ERROR!" in a computer program---which shows that "computer errors" are really designer or programmer errors), or you might decide that you'll defer all extraordinary circumstances until later. It's essential to confuse yourself about only a few things at a time.
Okay, you now have a lot of roles, but you're not even close to finished. Now you must figure out how the actors playing those roles are to collaborate to do their jobs. Identifying the set of roles you need is like establishing the vocabulary of your problem, now you must establish the semantics of the problem so that you can express role relationships. Example, a guest is checking in and hands a credit card to the desk clerk, the clerk checks the guest's credit with the appropriate credit card company; if there's a problem the clerk may need to call the manager, who may decide to take the risk depending on whether the guest has stayed at the hotel before, which requires a check of past guestlists, and perhaps also a call to the accountant to see if the hotel's bank account can survive the potential loss, and so on. Currently, there's no single role responsible for the job of "checking in a guest"; many roles---the guest, the desk clerk, the manager, the credit card company, the accountant, the hotel's bank, the guestlist (if you had made that a separate role rather than just a property of the desk clerk), all play their parts by communicating back and forth between themselves.
All right, that's enough overview. It's time to start learning the details of Java so that we can eventually build our way to interesting programs. You are about to enter a curious world where the only real limits on what you can build are your own.