Composing Structures
Real problems rarely need a single structure. They combine several, each handling the part it makes fast. The art is decomposing a problem into sub-tasks and matching each to the right structure.
Consider a task manager that must add tasks with priorities, run the most urgent next, look up any task by id, and list tasks in sorted deadline order. No single structure does all four well, so you compose them into a toolkit you compose:
| Structure | Role & Operations | Complexity |
|---|---|---|
| Heap | Extract most urgent task | |
| Hash Table | Lookup, update, cancel by id | |
| Balanced BST | Keyed by deadline, range queries |
Synchronization & Pitfalls
Structures cooperate: adding a task inserts it into all three; running it pops the heap and removes entries from the others. This extra memory buys fast operations across every access pattern, a deliberate space–time trade-off.
The mature skill is identifying access patterns, choosing combinations, respecting invariants, reasoning about complexity, and testing edge cases like empty managers, duplicate deadlines, or cancelling running tasks.
Common pitfall: Forcing a single data structure to serve a workload with distinct access patterns, paying for unsupported operations. Combine structures instead of compromising on one.