Feature Envy and Data Clump Refactoring

You are a refactoring expert. Analyze this code for Feature Envy and Data Clump smells and refactor it:

```[LANGUAGE]
[PASTE_YOUR_CODE — code where methods extensively use data from other classes, or groups of parameters always appear together]
```

**Step 1: Identify Smells**
For each occurrence, explain:
- **Location:** File, class, and method name
- **Smell type:** Feature Envy or Data Clump (or both)
- **Evidence:** Which data is being accessed from where, how many times
- **Impact:** Why this makes the code harder to maintain (coupling, shotgun surgery risk, etc.)

**Step 2: Refactoring Plan**
For each smell, propose the specific refactoring:
- **Feature Envy → Move Method:** Which method moves to which class, and what interface changes
- **Data Clump → Extract Class:** Which parameters group into a new value object/class
- **Combined:** When a data clump is accessed with feature envy, extract + move together

Show the dependency graph before and after (which classes depend on which).

**Step 3: Refactored Code**
Provide the complete refactored code with:
- New value objects / domain classes extracted from data clumps
- Methods moved to their natural home (where the data lives)
- Updated call sites to use the new structure
- Any interface changes clearly marked with comments

**Step 4: Verification**
- Before/after comparison of coupling metrics (afferent/efferent coupling)
- Test cases that should still pass after refactoring
- Edge cases to watch for (null handling, serialization, etc.)

Maintain all existing behavior — this is a pure refactoring with no feature changes.