Design Extensible Spreadsheet Aggregation APIs

Design an extensible spreadsheet aggregation API supporting `get_sum`, `get_max`, and `get_min`. Explain how a new aggregate can be added without duplicating range traversal and cell evaluation logic. ### Constraints & Assumptions - Cells may hold values or formulas; aggregation should consume computed values through one evaluation interface. - Specify how a range is represented and whether endpoints are inclusive before presenting the API. - The source names the three aggregate APIs but does not fix a formula grammar, empty-range policy, or numeric-error policy. State coherent choices rather than claiming those details are given. - Concentrate on interfaces, reuse, correctness, and complexity. No distribution or throughput requirement is supplied. ### Clarifying Questions to Ask - Are aggregations over contiguous rectangular ranges, arbitrary cell lists, or both? - What should an empty range, unset cell, nonnumeric cell, or cyclic formula produce? - Should future operators include averages or operators that cannot be expressed as a simple binary reduction? ```hint Separate fetching from reducing One component should decide which cells are visited and how they are evaluated. Another should own the aggregate's state and its final result. ``` ### What a Strong Answer Covers - A range abstraction and a cell-value evaluator shared by sum, maximum, and minimum. - An aggregate interface with initialization, accumulation, and finalization. - Explicit empty-input and evaluation-error semantics. - A worked extension such as average whose state differs from its return type. - Complexity that includes dependency evaluation and avoids evaluating shared dependencies repeatedly within one request. ### Follow-up Questions - What additional property would allow an aggregate to combine partial results from disjoint chunks? - How would cached aggregate results become invalid after a referenced cell or formula changes?