Implement classes in existing abstract hierarchy

Quick Overview

This question evaluates object-oriented design and implementation skills in Python within the Coding & Algorithms and software engineering domain, focusing on completing concrete subclasses in an existing abstract class hierarchy while preserving public interfaces and type compatibility.

Company: Bloomberg

Role: Software Engineer

Category: Coding & Algorithms

Difficulty: medium

Interview Round: Technical Screen

You are given an existing Python codebase that defines multiple classes, including abstract base classes using abc.ABC and @abstractmethod decorators. Without modifying public interfaces or abstract base classes, implement the missing logic in the concrete subclasses so that the system works end-to-end. Constraints: 1) Honor the Liskov Substitution Principle; any place expecting a base type must work with your concrete types. 2) Do not change method signatures, inheritance, or module-level APIs; implement only TODOs in concrete classes. 3) Clearly separate responsibilities (e.g., parsing, validation, and execution) using composition where appropriate. 4) Ensure correct handling of edge cases and error propagation as indicated by docstrings and type hints. 5) Provide unit tests that demonstrate the behavior of each implemented class and key interactions. 6) Briefly explain how you navigated a large (≈200 lines) skeleton with abstract methods to identify implementation points and avoid confusion.

Overview: This question evaluates object-oriented design and implementation skills in Python within the Coding & Algorithms and software engineering domain, focusing on completing concrete subclasses in an existing abstract class hierarchy while preserving public interfaces and type compatibility.

You are given a Python skeleton for an in-memory key-value command processor. The skeleton contains abstract base classes such as Parser and Command, with concrete subclasses left as TODOs. Without changing public method signatures, inheritance, or module-level APIs, implement the concrete parsing, validation, and execution logic. The processor must support updates, prefix-sum queries, error propagation, and rollback of successful mutations. Your implementation should honor the Liskov Substitution Principle: any concrete Command must be usable anywhere the abstract Command type is expected.

Constraints

0 <= len(commands) <= 200000
1 <= len(key), len(prefix) <= 30
-10^9 <= value, delta <= 10^9
All prefix sums fit in a signed 64-bit integer
Only successful SET, ADD, and DELETE commands are undoable; GET, SUM, invalid commands, and ROLLBACK itself are not recorded as mutations

Examples

Input: (['SET apple 3', 'SET app 2', 'SUM app', 'ADD apple 4', 'GET apple', 'SUM ap'],)

Expected Output: ['5', '7', '9']

Explanation: Both app and apple match prefix app for a sum of 5. After adding 4 to apple, apple is 7 and the sum for prefix ap is 9.

Input: (['GET missing', 'DELETE missing', 'SET x 10', 'DELETE x', 'GET x', 'ROLLBACK 1', 'GET x', 'ROLLBACK 2', 'GET x'],)

Expected Output: ['NULL', 'ERROR', 'NULL', '10', 'ERROR', '10']

Explanation: Deleting a missing key is an error. Rolling back one successful mutation restores x. Rolling back two more mutations fails because only one undoable mutation remains.

Hints

Use concrete command objects with common validate and execute methods so the processor can treat them polymorphically.
For efficient SUM prefix queries under updates and rollback, maintain a running total for every prefix of each key whenever that key changes.