##Learning Competencies
- Create well-defined classes with a single responsibility
- Identify and implement classes based on real world requirements
- Implement clean and flexible interfaces between objects
- Create interactive command-line applications with data persistence
##Summary
Let's build a simple flashcard game in Ruby with a command-line interface. Here is an example of one possible implementation:
$ ruby flashcards.rb
Welcome to Ruby Flash Cards. To play, just enter the correct term for each definition. Ready? Go!
Definition
A file format in which values are delimited by commas.
Guess: YAML
Incorrect! Try again.
Guess: XML
Incorrect! Try again.
Guess: CSV
Correct!
Definition
(and so on)
##Releases
###Release 0 : Design
####Choose Your Data Model and Control Flow
You might already have a clear picture of how to design your program, but it is always a good idea to articulate your concept using pseudocode, wireframes, or another modeling tool. You should be able to draw or write out a rough sketch of both the data model and the control flow of the program.
You don't have to go full-TDD on this, but it might be beneficial to create a rough (pseudocode) plan of how you'll end up testing it. This will be pretty high-level, e.g. "we'll test the guessing mechanism by [do something] and checking if [something happened]".
This stage should take at most 15-20 minutes. If you're spending more than that, find a staff member to get you unstuck.
Some questions to consider:
- Do you fully understand the logic of the game?
- What classes (state and behavior) do you need?
- What are the responsibilities of each class? Are they single responsibilities?
- Which methods should be public? Which should be private?
- Will your design be amenable to testing?
Once you have a plan in place, create the skeletal file structure for your app.
Find a staff member or another student and get their opinion on your overall structure.
The next step is to answer the question of where the cards will come from. Provided in the repo is a file called sample_cards.txt, which demonstrates a supremely basic way to store the card data (definition on one line, term on the next, and then a blank line to separate the two). In other words, the file looks like:
definition1 definition1 definition1 etc.
term1 term1 term1 etc.
definition2 definition2 definition2 etc.
term2 term2 term2 etc.
You can use this same file format for your cards if you like, or you can create your own. Just don't get too fancy. Remember, we're keeping it simple.
###Release 1 : Build it!
Now that you've got a general sketch for your app design and some sample data to work with, it's time to build out your app.
Think carefully about how each piece of the puzzle should fit together. Build it out slowly and test as you go. Skip the user interface (the part of your program that will receive and respond to user input) for now. You can mock user input by creating a method on one of your classes that takes a guess as an argument and performs the appropriate action. Later you can hook this up to real, live user input.
Some questions to consider:
- How will you generate card objects from the source file?
- How will your classes interact?
- Where should the game logic live? What about the file parsing?
By this point, you should have all of the core components of your application built out. In other words, your code should be an accurate model of the ingredients needed for a real-life flashcard game. Are you missing anything?
Finally, it is time to implement the interactive part of the game: the piece that will actually let you play with it via your very-own custom interface.
Think about what kinds of inputs and outputs your interface will handle and write the code to match for them.
Some questions to consider:
- How should you check for whether the user's answer is correct? Where should this logic live?
- What happens when a user starts the game?
- What happens when a user finishes the game?
- How will you handle incorrect answers?
Finish building out your app. Make sure everything works peachy keen.
##Optimize Your Learning
Consider your choices:
- Why did you organize your classes and logic in the way that you did?
- What have you learned about object-oriented thinking?
- How flexible is your code? For example, how many changes would you have to make in how many different files to allow for users to see the first letter of the answer? What if you wanted to allow case-insensitive answers?
##Resources
SPOILER ALERT: These contain solutions to the Todo challenge - make sure you have solved it on your own first!