By the end of this lab, you will be able to:
Your first task is to download the Twitter code based on this week’s
lectures into your lab2 folder, and open it in PyCharm. Review the code from class, and
ask your TA if you have any questions. Then, complete each of the TODOs found in that file in
the following order (we’ve arranged these roughly by difficulty).
User.verbosity method.retweet function should go into, and then move
it. (You’ll have to make some minor modifications to the code as well.)User.hack method.Create a new Python file in your lab2 folder and name it registry.py. Your task is
to perform an object-oriented analysis of a problem specification, outlined in the steps below.
Note: design is often harder and more time-consuming than implementation! Work with a partner, and don’t be afraid to take up the rest of the lab time to get a really solid design done. You’ll find that if you spend your efforts today on the class design, actually implementing your design will be comparatively straight-forward. Don’t begin implementation until your design is complete.
Read the problem description. Download specs.txt into your
lab2 folder and read through the problem description.
Decide what classes you need to design. In a basic object-oriented design, each class
usually models some noun in the problem description—but not every noun needs a class to model it.
For example, an email address can be modelled by a simple str. The one class you need
for sure is a class to represent the race registry as a whole. You can design a reasonable solution
that has only that class. Decide whether you wish to have any other classes.
Sample usage. Next, picture how your classes will be used by writing some doctests in the class docstring of one of your new classes. Your doctests should illustrate the following behaviour.
Remember, you haven’t written the class(es) yet! Just like function doctests help illustrate the purpose of a function, your class docstring helps the user (and yourself!) understand how your class should be used.
Designing the interface. Use Part 1 of the Class Design Recipe to create the public interface of each class. (You’ve already started doing this in the previous step.) Note that this involves a lot of documentation and writing of basic examples and tests, but still no implementation whatsoever. That will come later.
This analysis will require a fair amount of thought. Don’t worry about getting it completely right—you find any ambiguities in the specifications, write them down, and try to come up with a solution you think is reasonable. A good skill to develop in this course is identifying ambiguities and proposing multiple solutions for such ambiguities in problem descriptions you receive. There’s no “one right answer” to this task!
If you still have time, take your design and implement all of the methods in each of the classes you defined.
We’ve provided code in the “main” block at the bottom of the file to run doctest to check your
doctest examples. You should have already written a doctest example in your class docstring by following the
above instructions; make sure you add some further examples to individual methods to help check the
correctness of your code.
Here are some extra exercises that you might like to do after the lab to get more practice. We certainly don’t expect you to complete these exercises in the lab, but they are here for additional practice. These are generally a little more challenging, but are great checks for whether you understand all of the course material and can apply it to new situations.
Here are some additional exercises in designing and implementing classes. Each section in that file is a problem description for you to model using an object-oriented design.
As the problems get larger, it becomes more important to be able to focus on high level design before getting into details. We can record a high-level design with a simple drawing. Here is a design for our Twitter example in this style. Notice that this drawing omits details such as what type we should use for each piece of data, what parameters each method should have, and so on. We can decide on these later, once we have settled on the overall design.
Read the specifications for this larger problem in specs_larger.txt. Circle the nouns and underline the verbs.
Using the same diagram style as in the example above, come up with a design for this software. There is a lot of judgment involved, and there are multiple good solutions. The point here is to think about and debate some options, and start to get comfortable with the process.