Design an object-oriented rule engine that evaluates declarative rules against a record. The rule language must support comparison predicates such as equality and numeric ordering, boolean composition with `AND`, `OR`, and `NOT`, and reusable named fields. New operators should be addable without placing a large type switch in the evaluator. Show representative interfaces or class shapes and walk through evaluating a nested rule. ### Constraints & Assumptions - A missing field is distinct from a field whose value is `null`. - Type mismatches must produce a defined result or error rather than language-specific coercion. - Rules can be parsed once and evaluated against many records. ### Clarifying Questions to Ask - Should evaluation short-circuit? - How are invalid rules reported and versioned? - Are side-effecting operators allowed? ```hint Separate syntax from behavior An abstract syntax tree can describe the rule while operator objects own validation and evaluation semantics. ``` ### What a Strong Answer Covers - Interfaces for expressions, predicates, values, and evaluation context. - Parsing and validation before runtime evaluation. - Missing data, nulls, type checking, short-circuiting, errors, and testability. - Safe extension, immutability, and caching of compiled rules. ### Follow-up Questions - How would you add a SQL-like filter syntax without coupling the parser to storage? - How would you explain which subexpression caused a rule to fail? - What restrictions are needed if users can author rules?