Week 1 ¡ª Flashcard Study App

Terminal Utility ¡¤ Java

The Idea

Flashcards are one of the oldest and most effective study techniques ¡ª but most digital implementations are either too simple (just flip a card) or locked behind an app you don't control. You're going to build your own, in the terminal, tailored to how you actually want to study.

The core idea is simple: you have a deck of cards, each with a question and an answer, and the program quizzes you on them. But not all cards are the same kind of question. Some are plain text ¡ª "What is polymorphism?" ¡ª where you just type your answer. Others are multiple choice, where you pick from a list of options. These feel similar on the surface, but the way you ask the question and the way you evaluate the answer are completely different.

That difference is what this project is built around. You decide how many card types you want to support, what the study experience feels like, and how the scoring works. The only constraint is that a study session can hold any mix of card types and work through them the same way ¡ª without ever needing to know what kind of card it's dealing with.

Week 1 ¡ª Build Your Card Hierarchy

This week is about the cards themselves ¡ª before scoring, persistence, or a polished interface.

This week's topic: classes and subclasses.

You need to model the fact that all cards share a common structure (a question, a way to be asked, a way to be evaluated) but differ in how those things actually work.

You need:

• An abstract base class Card that holds what every card has in common. The methods that differ per card type ¡ª at minimum ask() and evaluate(String answer) ¡ª should be declared abstract.
• At least two concrete subclasses: TextCard for open-ended questions and MultipleChoiceCard for questions with a numbered list of options. Each must hold its own relevant fields ¡ª an expected answer string for one, a list of options and a correct index for the other.
• A Deck class (not a subclass of Card) that holds a named collection of cards and lets you add and retrieve them.
• A basic study loop ¡ª the program iterates through the cards in the deck, calls ask() on each, reads the user's input, and calls evaluate() to check it. Just print "Correct!" or "Wrong" for now.

By the end of week 1 you should be able to run the program, have it quiz you on a hardcoded deck of mixed card types, and see whether your answers are right.

What you decide:

• What fields Card holds (unique ID, a hint, a difficulty level ¡ª up to you)
• Whether evaluate() is case-sensitive, allows partial answers, or is strict
• How MultipleChoiceCard displays the options
• Whether a Deck has any structure beyond a flat list

Scoring and repetition logic comes in later weeks ¡ª for now, just getting through the cards once is the goal.