Week 1 ¡ª CLI Task Manager

Terminal Utility ¡¤ Java

The Idea

Every developer ends up building a to-do app at some point ¡ª but most of them are throwaway exercises. This one isn't. You're building a task manager you could actually use: something that runs in your terminal, remembers what you've added, and helps you stay on top of what needs doing.

The interesting design challenge is that not all tasks are the same. Some have a hard deadline ¡ª finish by Friday or it's too late. Others repeat ¡ª take out the bins every Sunday, review notes every morning. These feel like the same thing on the surface ("a task") but behave completely differently when you ask "is this due right now?" That distinction is what this project is built around.

You decide what the interface looks and feels like, what information a task stores, and what the command names are. You also decide whether tasks belong to projects, whether there are categories or priorities, and what "done" actually means for a recurring task. The only constraint is that your system can handle both deadline-based and recurring tasks, and treats them uniformly when displaying and checking them.

Week 1 ¡ª Build Your Task Hierarchy

This week is about modelling what a task is before worrying about filtering, persistence, or the full CLI.

This week's topic: classes and subclasses.

You need to capture that all tasks share some things (a title, a priority, tags) but differ in how they decide whether they're currently due. That's the core split.

You need:

• An abstract base class Task that holds everything all tasks have in common. The methods that differ per task type ¡ª at minimum isDue() and display() ¡ª should be declared abstract.
• At least two concrete subclasses: one for tasks with a fixed deadline (DeadlineTask) and one for tasks that recur on a schedule (RecurringTask). Each must hold the fields its logic needs ¡ª a deadline date for one, a frequency and last-completion date for the other.
• A Project class (not a subclass of Task) that holds a collection of tasks and lets you add and list them.
• A basic CLI loop ¡ª a simple read-eval loop that accepts at least add and list commands.

By the end of week 1 you should be able to start the program, add a couple of tasks of different types, and list them all back.

What you decide:

• What fields every task has (title, priority, tags ¡ª you choose what's useful)
• What "recurring" means ¡ª daily, weekly, custom intervals?
• Whether Project is the top-level container or whether you have something else
• What the command syntax looks like

The logic inside isDue() doesn't need to be perfect yet ¡ª a simple check is fine. You'll refine it in later weeks.