You have probably used flash cards to help you
memorize something. They have a "question" of some sort on one side, and
an "answer" on the other. You use them by looking at the
question, trying to remember the answer, then turning the card over to
check your memory. If you were trying to learn the multiplication
table, a card might have
6 x 9 on the front,
54 on the back. Or, if you were trying to learn the U.S.
state capitals, a card might have
Pennsylvania on the front,
Harrisburg on the back.
Your assignment is to write a program to let you work with a set of
"digital" flash cards. There will be two separate classes with a
main method: A class named
Study, used for learning the cards, and a class named
Build, for creating the cards. Each main class will have its own GUI, and you can run the program starting in either class, depending on what you want to do.
When the program starts, it needs to read in all the cards, along with information about how well the card has been learned, and when it is next scheduled to be displayed.
When you are studying flashcards, the following sequence of events occurs repeatedly:
Easy, meaning you had no trouble thinking of the correct answer.
Moderate, meaning you got the correct answer, but you would like more practice with it.
Difficult, meaning you either didn't know the answer, or you had to think hard to get it.
There should be some way to quit the program. For example, the user might decide ahead of time how many cards to study, or study until some goal is reached. If the user closes the window, this should also quit the program, but it shouldn't be the usual way to quit.
The program needs to keep track of how well each card has been learned, and schedule it appropriately. If the user said a card was "difficult," it should be presented again fairly soon; if "easy," it should be a longer time before the user sees it again. Use the following scheme:
Easy, then the interval should be multiplied by some factor greater than one, possibly 2 or 3.
Moderate, then the interval should be multiplied by some factor, possibly 1.
Difficult, then the interval should be reduced by some factor. However, there should be some minimum beyond which the interval cannot be reduced (I suggest something between 5 and 8).
When the program ends, save all the card data to a file, so that the next time the user runs the program, they will continue their studies just as if they had never quit. This file will be read in the next time the user runs the program.
Debugging is a lot less fun than adding features to a program. However, responsible programmers make sure their programs work correctly before they add frills. After all, which would you rather drive--a car with a great stereo system, or one with reliable brakes?
That said, there are some things that you can do to improve the program. Some people don't like taking their hands off the keyboard, so you could provide keyboard equivalents (such as
d) for clicking buttons. The program can be made more interesting by providing some measure of progress (cards studied, cards learned, etc.)
Your program will be graded on basic functionality first. If everything seems to work correctly, and if whoever grades your program thinks you did an especially good job, you may get a small amount of extra credit. This will be wholly subjective--if the grader likes your program, he or she may award some extra points; but only if the program is otherwise error-free.
Just as important as studying the cards is creating them in the first place. Here's the absolute minimum that the
Build class has to do:
Your program should do basic consistency checking. Two things in particular to watch out for: Don't allow any cards to have a blank question or a blank answer; and don't allow two cards to have the same question (duplicate answers are okay, though).
I've listed this as an "extra" because it isn't necessary if only one person will ever use the program, but treat it as a requirement. It should be easy enough to do.
The comments about extra functionality for the
Study class also apply here. Debug your program thoroughly before adding frills.
If you get this far, though, one really nice feature to add is an Undo capability. This can involve a surprising amount of extra code, so don't tackle it lightly.
You and your partner will both need to read in and write out a file of cards, so this should be shared code, in a separate class.
A fundamental decision to be made is whether to keep the file of cards as a text file, or as a binary file. A binary file is somewhat easier to write out and read in, but a text file is humanly readable. In most cases I prefer the flexibility of a plain text file, but the decision is yours.
When deciding how to format the card file, remember that the "scheduled time" doesn't mean anything unless you know what time it is "now."
This program divides fairly neatly into two parts, with some shared functions (such as I/O). Nevertheless, as usual, you and your partner will receive the same grade on the program, so work with your partner to make sure everything is correct.
Follow the MVC pattern! The GUI is your Controller, manipulating the cards, but also acts as a View. The Model accepts commands from the Controller, acts on them, and makes the results available to the View. The Model does no I/O, either to the GUI or anywhere else; it just quietly does what it is told to do.
The above are requirements. You may have additional classes and methods as needed, and they should be documented and unit tested as appropriate.