cs108 → oop → lab13

In this lab, you will work with a quiz application that asks a sequence of questions of the user. The interface is shown here:

The application displays problems in a text area (on the top) and messages (on the bottom right); the user types answers in a text box (on the bottom left) and presses enter.

Three classes work together to create the application:

Controller - implements a GUI driver for a quiz
Quiz - implements a simple quiz with short answer problems
- Keeps track of current problem
- Randomizes the order of the problems
- Keeps track of whether or not all problems have been used
ShortAnswer - implements a simple problem class with a string question and string answer
- Provides interface for asking the question
- Provides interface for checking if a provided answer is correct

Exercise 13.1

Create a new package for this lab called lab13 and copy the starting code files into this package:

Familiarize yourself with the quiz mechanism by doing the following:

Run the controller a couple times;
Run the unit tests for the ShortAnswer problem class
Add a new short-answer problem (of your choice) to the quiz

Inheritance

Right now our quiz mechanism can only ask short answer problems, but this is a bit too limited for our purposes. We'd like to add fill-in-the-blank problems, true-false problems, and maybe even multiple choice problems. As we start planning, we realize that we will be duplicating code if we write each kind of problem from scratch. Instead, let's start with a Problem class that will be the parent class of all the different kinds of problems. This class will collect all of the attributes and methods that are shared between all problems.

So what is shared between all problems? Each problem has some text, but asks the question in a different way (e.g. short-answer just added a question mark, but a fill-in-the-blank problem should add both the question mark and an indication to "Fill in the blank."). Further, all problems have answers, but a true-false problem has a boolean answer instead of a string. Considering these properties, we proceed as follows:

Exercise 13.2

Refactor your code to include a Problem class and a ShortAnswer class that inherits from Problem.

The new Problem class:

Includes a constructor that receives a string and stores it in an instance variable called self.text
Includes an accessor for the question called get_text()
Put this in a separate file.

The updated ShortAnswer class:

Has an updated class declaration that indicates it is inheriting from Problem
Has an updated constructor:
- Calls the Problem constructor to initialize the text instance variable (instead of doing the assignment statement itself): Problem.__init__(self, q)
- Does not remove or change the initialization of the answer instance variable
Has an updated ask_question method that replaces the access of self.text with a call to the appropriate accessor in the Problem class and then appends the question mark: self.get_text() + '?'
Removes the get_text method (since the Problem class is taking care of this for us).

If all has gone well, your controller should run just as it did before, and all of the ShortAnswer tests should still pass.

Python does not require that the question class definitions be placed in separate files, but it is common practice to separate more complex classes into separate files. These question classes are probably simple enough that they can be kept together, but if you choose this option, you should rename the file to “problem” to more accurately indicate what it contains.

Polymorphism

We are now ready to add more types of problems, such as true-false problems and fill-in-the-blank problems. Examples of how your application should present these questions are shown below:

The new problem classes are very similar to a ShortAnswer problem, but they each have differences:

The FillInTheBlank class is very similar to the ShortAnswer class (so similar we should maybe not have a whole separate class, but this is for learning purposes, right?) with the following modification:
- The ask_question method must append the string '\nFill in the blank.' to the end of the problem text instead of just a question mark.
The TrueFalse class is also similar, but with a few more details to be worked out:
- The answer is expected to be a boolean value, so the constructor should raise an exception if the calling program provides an answer that is not an instance of bool. You can check that answer is boolean using: isinstance(answer, bool).
- The ask_question method must append the string '\nIs this statement true or false?' to the end of the problem text.
- The get_answer method should return a string (to match the other problems): str(self.answer)
- The check_answer method will receive a string, so we must compare a string version of the correct answer to the received answer.

Because all problems are using the same method names, the quiz will be able to create a list of Problems, and ask each problem to ask its question, check its answer, and tell us the correct answer.

Exercise 13.3

Do the following (if you haven't already):

Add the FillInTheBlank and TrueFalse classes as described above.
Add some unit tests to the test cases at the end of the file(s).
Add at least one sample problem for each of the two new classes to the quiz.

Your quiz application should now operate as it did before, with randomly ordered questions of all three subtypes.

Checking In

Submit the final version of all of your files. We will grade this exercise according to the following criteria:

Correctness:
- 40% - exercise 13.2 - Add the required inheritance.
- 40% - exercise 13.3 - Configure the polymorphic behavior.
- 10% - New questions of each type are added
Understandability:
- 5% - Header Documentation - Document the basic purpose, authors and assignment number for each file.
- 5% - Code Documentation - Separate the logical blocks of your program with useful comments and white space.

If you’re working on a lab computer, don’t forget to log off of your machine when you are finished!