$ mkdir ~/cs170/labs/lab8 $ cd ~/cs170/labs/lab8
Again, it is on Inquire. This time, you only get one shot, however. So make this one count! When you get done with the Quiz, you can start working on Activity 1 until everyone finishes the Quiz.
As you are probably aware, the college keeps a directory of everyone affiliated with the college accessible for anyone to search. It is located on the main page of roanoke.edu. Everyone has certain information, but there is more information stored for certain classifications of people, such as Faculty or Staff. This sounds like a great opportunity to practice some Inheritance syntax.
In a file called directory.py, create 3 different classes:
, Student, and Faculty.
For now, we are just worried with storage, so you don't need to worry
about methods for any of these classes. Both Student and Faculty will
inherit the People class. You simply need to work out what
information is common between Students and Faculty; Any shared
information should go into their shared parent class, People.
For the sake of this program, you should store the following information:
Once you have finished with the class definitions, test them by creating several Students and Faculty. Make sure you can access the appropriate attributes of each object, and that you are not storing any unnecessary attributes for each class.
On Friday, we used a Dictionary to store the list of students. However, we aren't always going to be able to use Dictionaries to solve our problems. In fact, using a Dictionary for something like the directory search would be a bit of a waste of memory.
Instead, we could simply store all of the people you have created into a list. Then, whenever someone is looking for information for a particular person we just have to find they entry in that list.
Modify your program so you can interactively search and print information about people. You should use a list this time, instead of a dictionary.
On Monday, you saw how we can create classes that inherit methods (and attributes) from another class. However, It is not entirely clear why doing that might be useful. Let's explore what inheritance give us.
I'm sure most of you have played at least one game of Monopoly in your life. The game consists of a set of 40 squares containing 28 properties, 6 Action squares, 2 Tax Squares, "Go", "Jail", "Free Parking", and "Go To Jail". You play the game by moving through the set of squares based off of the roll of the dice. You perform a different action based on which square you land on. For example, if you land on a property, you either have to pay "rent", or you can purchase the property. However, if you land on an "Action" square, you have to draw a card from a certain pile. "Tax" squares require the player to pay some fee to the Game's banker.
Relax, I wouldn't be evil enough to force you to create the whole game of Monopoly in lab. However, this is a great example of Inheritance, since ALL of the squares need some information, but you need to change the behavior of certain squares. We will work on a relaxed scenario for this.
I am not going to force you to start on paper for today. However, I would strongly suggest you at least think about designing on paper first, then start your coding.
You are required to create 4 classes for the Monopoly program:
MonopolySquare, PropertySquare,
ActionSquare, and TaxSquare. Your other
three squares will inherit the MonopolySquare class, which should
just have a single attribute: The name of the square. It should
also have a method land_on(), which does nothing by
default. The derived classes should print the action the player
should take.
Once you have written all four classes, you should create a simple program that creates a list of at least 12 squares (Make sure there is at least one of each type), "rolls the dice" by selecting a random square from the list, and prints a message indicating which square the player landed on and the action they should take.
You can actually get away (for now) without any additional attributes of the child classes. We are simply changing a behavior, not the description. So you don't need to define a constructor, just inherit one from the parent class.
Because all of the child classes inherit the Monopoly square,
you are guaranteed that each one will have a
land_on method. This method should be overridden
in each of the child classes, printing a message indicating the
action the player should take..
Make sure you wrap your head around what is going on here. You now have 4 new data types, but they are now all related in a family tree like structure.
You now can create Monopoly squares. Why not make a class that represents an actual Monopoly game? This class has a different relationship to the Monopoly squares. You won't inherit them, but you will create 40 of them to represent a game board.
You should also modify the other classes that you wrote previously to interact with your game board appropriately. For example, instead of instructing the user on what to do, actually perform said action. Your "Action" squares can immediately draw an action card, "Tax" squares can immediately deduct money from the appropriate player, etc.
You may need to write some additional classes for this as well. Think about the relationship between your classes, to determine when and where inheritance should be used, as opposed to storing information in attributes..
When you have finished, create a tar file of your lab8
directory. To create a tar file, execute the following commands:
cd ~/cs170/labs tar czvf lab8.tgz lab8/
To submit your activity, go to cseval.roanoke.edu. You should
see an available assignment called Lab Assignment 8.
Make sure you include a header listing the authors of the file.