Coding

Refactor the provided code to improve its quality along the specified goal while preserving identical external behavior, and explain the reasoning behind every change.

REFACTORING PROCESS:

1. Code Assessment
   - Read the code and summarize what it currently does (to confirm shared understanding)
   - Identify code smells: long methods, deep nesting, duplication, poor naming, tight coupling, god objects, feature envy, primitive obsession, etc.
   - Map which smells align with the stated refactoring goal

2. Refactoring Plan
   - List the specific refactoring techniques you will apply (Extract Method, Rename Variable, Replace Conditional with Polymorphism, Introduce Parameter Object, etc.)
   - Order changes from lowest risk to highest risk
   - Identify any changes that might affect the public interface and flag them

3. Execute Refactoring (by goal)

   For READABILITY:
   - Improve variable and function names to reveal intent
   - Extract complex conditionals into well-named boolean functions
   - Reduce nesting depth (early returns, guard clauses)
   - Break long functions into focused, single-purpose functions
   - Replace magic numbers/strings with named constants
   - Add or improve type annotations

   For PERFORMANCE:
   - Eliminate redundant computations and unnecessary allocations
   - Optimize data structure choices for the access patterns used
   - Reduce algorithmic complexity where possible
   - Minimize I/O operations and batch where applicable
   - Add caching for expensive repeated operations
   - Include before/after complexity analysis

   For MAINTAINABILITY:
   - Apply SOLID principles and reduce coupling between components
   - Extract reusable abstractions and eliminate duplication
   - Introduce interfaces or protocols where concrete dependencies exist
   - Improve error handling consistency
   - Make the code more testable by injecting dependencies
   - Separate concerns into distinct modules or classes

4. Validation
   - Confirm the refactored code produces the same outputs for the same inputs
   - Note any behavioral edge cases that should be verified with tests

OUTPUT CONSTRAINTS:
- Show the complete refactored code, not just changed snippets
- Annotate every change with a numbered explanation of what changed and why
- If a change involves a trade-off (e.g., more code for better readability), acknowledge it
- Do NOT change external behavior, function signatures, or return types unless explicitly discussed
- If the code is already good in some areas, say so; do not refactor for the sake of refactoring

FORMAT:
## Assessment
[What the code does and what smells were identified]

## Changes Made
1. [Change description] - [Why it improves the code]
2. ...

## Refactored Code
```
[complete refactored code]
```

## Before/After Comparison
[Key metrics: lines of code, nesting depth, cyclomatic complexity, or Big-O if relevant]

---

MY INFO:

Goal (readability / performance / maintainability): (required)

Code to Refactor: (required)

Programming Language: (optional)

Constraints (must keep specific interfaces, backward compatibility, etc.): (optional)

Context (what this code is part of, how it is called): (optional)