[Tutor] designing POOP

[bhaaluu]

On Feb 9, 2008 4:09 AM, Alan Gauld <alan.gauld at btinternet.com> wrote:
>
> "Tiger12506" <keridee at jayco.net> wrote
>
> > Are some simple examples off the top of my head. It's not difficult
> > to model
> > real-life things with classes, but ...
>
> This is a good point, it is excellent practice for thinking
> about the responsibilities of objects
>
> > ...it is much more difficult to model them
> > in such a way that you interact with them normally.
>
> And this is the bit that does require experience and careful thought.
> But even thinking in the absract about doors, knobs,locks etc helps
> to get the brain attuned to the kind of decions that need to be made

I'm really getting a lot out of this discussion. In my tutorial (PPftAB2E)
the second chapter deals with a Blackjack game. One thing I noticed
(and remember, this is a Noob's viewpoint): The classes seemed to be
designed from small to large, rather than from large to small. First,
a card class was made that had card-object stuff in it (suits and ranks).
Then a hand class was made that inherited the card class. Then, a deck
class was made, that inherited from the hands class (that already had
inherited from the card class). Is this the way you think about designing
classes (small to large). I don't know the proper terminolgy for that yet.

I'm almost ready to start working on another aspect of the adventure game.
I've noticed in my tutorial that several small programs introduce various
classes as the chapter proceeds, then at the end, it is all used to make
the final program. That's fine for the book: no telling how long, or what he
had to do to get it to work that way. But I'm just trying to figure out the
design of the adventure game in small increments. If, in the end, I can
use parts of these small programs to make the final program, great!
But for now, I'm trying to keep it at a manageable size while I'm learning.

There is a castle which has several levels and each level has rooms on it.
The rooms have doors. The doors connect the rooms to each other. Each
room can have either nothing in it, a treasure, or a monster. Each room
has a description which describes 1) Is there a treasure in the room? (and
if so, what is the amount), 2) Is there a monster in it (and if so, what is the
Danger Level), 3) The room description, including where the doors are,
(N,S,E,W,U,D).

I'd like to try and design this small part so that the Explorer can move
around the environment, from room to room, level to level. That's it.
The Explorer will be able to see, but not pick-up treasure (keeping in
mind that treasure can be picked-up in the final game). The Explorer
will be warned about a monster in the room (keeping in mind that the
monster can be fought in the final game).

Design in small chucks. The Castle needs to be setup. Can the Travel
Table from the procedural game be used? Setup requires that the
floorplan, or map of the castle be used to define each room on a level,
all the doors for the rooms, and treasure/terror. One array is used in
the procedural program. Whoops! Sorry. I'm not supposed to think
about it like that!

If I use the small to large approach: A door is the smallest part of a
room. Each room shares doors. Each floor has rooms. All the floors
are in the Castle.

But in this game, all the doors do is connect the rooms. They don't
have knobs or locks. They don't open or close. (Although they MAY
have that ability in some future game?). My thought is you can't
possibly think of all the future things an object can do or be, but
if the class is designed in a very abstract way, then it will be easier
to add a new behavior or characteristic in the future, if needed?
This is what I'm trying to learn with this adventure game exercise.

So, I'm thinking that a door class isn't necessary? The next thing
is a room. A room has doors that connect to other rooms, a
description, and may contain a monster or treasure. This sounds
like a candidate for a class?

The castle has levels. Each level has rooms. Everything happens
in the castle. The equivalent of the castle in the card game would
be the "deck of cards". But the deck of cards holds "hands" (rooms?)
which are shuffled and dealt to people. It does something. What does
the castle DO? It holds rooms, and monsters and treasure is shuffled
and "dealt" to random rooms (for the Explorer to find).

Not having much experience doing this, makes it harder than it
should be! What is your thought process on this?

>
> > door, or the knob? Does the knob contain a Lock, or does the
> > developer only
> > need to know that it has one and whether it is locked or not?)
>
> And its important to remember that the answers will be problem
> dependant.
> There is no absolute right or wrong, just what works best for your
> problem.
>
> Of course that's why building reusable objects is so hard.
> Something apparently reusable will usually only be reusable
> within a single problem domain. And even then may need to
> be tweaked for the specific problem. It has been estimated
> that building reusable objects costs between 3-5 times as
> much as building a bespoke version (and commercially
> reusable objects cost up to 10 times as much!)
>
> Alan G.
>
> _______________________________________________
> Tutor maillist  -  Tutor at python.org
> http://mail.python.org/mailman/listinfo/tutor

-- 
b h a a l u u at g m a i l dot c o m
"You assist an evil system most effectively by obeying its
orders and decrees. An evil system never deserves such
allegiance.  Allegiance to it means partaking of the evil.
A good person will resist an evil system with his or her
whole soul." [Mahatma Gandhi]