Section 18.3 - Any Structures Missing (Locating Operations)?

It's best to try to identify all the major components of a program and their purpose before going further. One way to do this is to think of important operations and data values and then determine if they have a "home" in our program structure. We've already covered the basic hierarchy of tagged types, and that seems to cover most of our needs. Let's think about the kinds of operations we'll need, and where they will be defined, to see if there are any that can't easily be located on our current design.

I think most of the commands should be attached to type Occupant (and thus placed in the Occupants package), with possible overriding for more specific types. You'd like to be able to command things other than the player to do things; it would be useful to command monsters and magic swords, for example. Even if you don't want a user to be able to "get" a monster, you want to print a reasonable message (not raise an exception) if the user attempts it. On the other hand, it's not as easy to imagine a room "getting" things (though you could define what that means), so for our purposes we'll attach many operations to Occupant.

The parser package will need to be able to command objects to Look, Get, Drop, and so on. It sounds like the operations like Look, Get, Drop, and so on will need to be in the specification of the various packages defining their corresponding tagged types. We'll come back to that later, but it looks like the structure we've developed so far will handle that easily.

The parser will need to break apart the text and then send a message to the player object to do something. Hmm, how can we find the player object? We could just define a global variable, but if this game ever became a multi-player game that wouldn't be very flexible. Let's define a function called "Me" that returns something that can represent the player. That way, we can create a function that varies who "Me" is easily.

Okay, where should that function "Me" go? It could be part of the Occupant class, but I'd rather have a separate package that sets up and keeps track of the "current state of the world". That way, all the other packages only need to react to specific commands and requests given to them, and they won't need (or even have available!) global information about the state of the world without specifically requesting that information. I'll call the package that keeps track of the general world state package "World".

We've already identified package Ustrings as a useful package, and I can't think of anything else we'd need, so it looks like we have a basic structure for program Small.

Quiz:

What new package have we identified?

You may also:

Go back to the previous section
Skip to the next section
Go up to lesson 18 outline

David A. Wheeler (dwheeler@dwheeler.com)

The master copy of this file is at "http://www.adahome.com/Tutorials/Lovelace/s18s3.htm".