[Tutor] designing POOP

[Alan Gauld]

"bhaaluu" <bhaaluu at gmail.com> wrote

> When you're designing a program, how do you go about dealing
> with text descriptions, like the descriptions for a room? Here is an
> example of a room description:
>
> THIS IS THE AUDIENCE CHAMBER
> THERE IS A WINDOW TO THE WEST. BY LOOKING TO THE RIGHT
> THROUGH IT YOU CAN SEE THE ENTRANCE TO THE CASTLE.
> DOORS LEAVE THIS ROOM TO THE NORTH, EAST AND SOUTH.

You can use a class attribute as per my other email example.
This attribute would contain %s markers to substitute the values
as needed. And finally the actual text can be loaded from
a data file by the init method.

> The player reads the description, and presses "W". There is no west 
> door.
> The program's output is:
>
> YOU CANNOT MOVE THROUGH SOLID STONE
>
> and back to the main prompt. Pressing "S" moves the player through
> the South door into another room, where the status of the player is
> displayed, and the description of the new room.

OK, See my other porst but you could use the castle as a
coordinator that determines which rooms are available from
any other room. You can build that knowledge into the
rooms - eg by passing the relationships in to the constructor
but that gets hard to maintain, especially in 3D. So I prefer
to have a coordinating object(the castle - or Kent suggested
a Map)

> The data.py file, with the room descriptions is the biggest file in 
> the
> procedural program. I've been told that a data class with a lot of 
> random
> data in it is a CodeSmell. Is a data class that has room 
> descriptions in
> it, with a function for each room, considered a bad design?

The data isn't the problem its the functions and data being mixed
in a class. Having a data file that classes use to set up common
data(class attribnutes) is perfectly valid.

> And, since the setup table and the function that decides which room
> description is closely related, couldn't they also be a part of that 
> data
> class? Is a data class a CodeSmell when all the functions are 
> related?

No a class with functions and the related data is exactly what you
want. What you want to avoid is a classs that has data for two or
more different object types. Or a class with only data.

> Or, should I have a room class that can instantiate 19 room objects
> which simply accesses the room functions from the data.py file as
> it is?

The room objects don't use the functions in data.py rather
those functions become the methods of the class and the data
gets loaded by those methods into the instances. Remember,
objects do it to themselves. Nothing outside the class should
be changing the internal attributes. But it is OK for the class
to load the data from outside - as in a config file.

This is a good thing because it allows you to change the
displayed messages without changing code. For example
to support multiple languages...

> As a side note: Really, the adventure game isn't too much different
> from the Bank Account program in your tutorial:: there are several
> accounts in the adventure game which are credited and debited
> as the game progresses. Pick up treasure: credit my wealth account.

Exactly so. And the ability to recognise that is a big step forward
in recognising abstraction.

Alan G