Problem statement
Design the object model and public APIs for the core of a personal task manager: the classes that hold tasks, group them into lists or projects, move a task through its lifecycle, and let the caller filter and sort the tasks in a list by different criteria. This is the in-memory domain library a UI or a sync layer would drive, not the app around it.
Operating context. A single user, one workspace held in memory. A task has a title, an optional note, a status (todo, in progress, done, archived), a priority (low, medium, high), and an optional due date. Tasks live in lists or projects, and a task may declare that it depends on other tasks that must be completed before it can start. Some tasks recur (every weekday, every month), so completing one should spawn the next occurrence from a rule rather than being copied by hand. A task can also register a reminder that some outside notifier will fire at a chosen time — the manager decides WHEN a reminder is due, but does not itself send anything. Callers frequently ask for a list's tasks filtered (only high-priority, only overdue, only a given status) and sorted (by due date, by priority, by created time), and want to combine those criteria freely.
Out of scope. Persistence and any database, the sync / networking layer and multi-device conflict handling, the actual delivery channel for reminders (push, email, OS notification), the UI / rendering surface, and authentication or sharing between users — model the in-memory domain objects, not the application around them.
What to produce. The class hierarchy (entities such as Task, List/Project, and the workspace root; value objects such as Priority, Status, a due date, and a recurrence rule; and the services that filter, sort, and advance recurring tasks), the public API each class exposes, and the states a task moves through with the transitions between them. Be explicit about: how filtering and sorting are expressed so a caller can compose several criteria without you editing existing code for each new one, how a recurrence rule produces the next occurrence when a recurring task is completed, how a task's dependencies block it from starting and how you keep a dependency cycle from forming, and how a reminder's due moment is computed and re-armed for a recurring task.
Functional requirements
- Create, edit, complete, and archive a task carrying a title, optional note, status, priority, and optional due date, and move it between lists or projects.
- Return the tasks in a list filtered by one or more criteria (status, priority, overdue, due within a window) combined together.
- Return the tasks in a list sorted by a chosen key such as due date, priority, or creation time, including a stable multi-key order.
- Declare that a task depends on other tasks, and refuse to start or complete a task while any of its prerequisites are unfinished.
- Advance a recurring task on completion by generating its next occurrence from its recurrence rule instead of duplicating it by hand.
- Register or clear a reminder on a task and report the moment at which that reminder is next due for an external notifier to act on.
Non-functional requirements
- Adding a new filter or a new sort key must not require editing existing filters, sorts, or the list class (open for extension, closed for modification).
- A recurrence rule is a pluggable unit: a new cadence (for example every second Tuesday) is added without changing task-completion or scheduling code.
- The dependency graph can never form a cycle: any edit that would introduce one is rejected, and the check is provably terminating.
- Task state transitions are total and explicit — every allowed move is defined and every disallowed move (such as completing a blocked task) is refused, not silently ignored.
- The domain core is deterministic and unit-testable with an injected clock, so recurrence, overdue, and reminder timing can be tested without the real wall clock.
- Filtering and sorting a list of N tasks run in predictable time — filtering O(N) per pass and sorting O(N log N) — with no hidden quadratic scans over dependencies.
Topics
- System Design LLD
- Patterns Strategy
- Oop Solid
- Statemachine
- Ds Graph