Problem statement
Design the object model and core APIs for a playlist manager that a media app uses so one listener can build, reorder, and play through ordered collections of tracks drawn from a local library.
Operating context. One user, single in-process service. A library holds thousands of tracks, each with an id, title, artist, duration, and free-form metadata. A playlist is an ordered sequence that references library tracks by id; a per-playlist policy decides whether duplicates are allowed. Users append, insert at a position, move, and remove entries, and play through with a cursor that advances from track to track. Shuffle visits every track once in a randomized order without disturbing the stored sequence. A smart playlist is defined instead by a predicate over track metadata and auto-includes every matching library track.
Out of scope. Audio or video decoding and streaming, on-disk persistence, cross-device sync, collaborative multi-user editing, and recommendation or ranking models.
What to produce. The class hierarchy (library, track, manual and smart playlists, play cursor), the public API each class exposes, and the cursor's state transitions. Be explicit about: the ordered-collection structure that keeps reorder and remove cheap, how shuffle is a pluggable strategy that never mutates the stored order, how a smart playlist re-evaluates its predicate, and how manual and smart playlists share one read interface so the player treats them alike.
Functional requirements
- Create a playlist and append, insert-at-index, move, and remove tracks while preserving order.
- Play through a playlist by advancing a cursor to the next or previous track.
- Toggle shuffle so playback visits every track once in a randomized order without mutating the stored order.
- Define a smart playlist from a predicate over track metadata that auto-includes matching library tracks.
- Deduplicate entries or allow duplicates according to a per-playlist policy.
- Query a playlist's length, total duration, and current cursor position.
Non-functional requirements
- Insert, move, and remove at a known index are O(log n) or better for an n-track playlist.
- The shuffle ordering is a pluggable strategy so a new ordering policy touches neither cursor nor playlist code.
- Manual and smart playlists expose one common read interface so the player consumes them uniformly.
- Advancing the cursor past the last track is a total, well-defined operation (stop versus a policy hook).
- The object model is unit-testable without audio hardware, injecting the randomness source used by shuffle.
- Adding a new track-metadata field must not force changes to the ordered-collection core.
Topics
- System Design LLD
- Media Playlist
- Patterns Strategy
- Patterns Iterator
- Oop Solid