[HIGH] Refactor App struct - Extract subsystem managers to reduce God Object complexity

[MichaelFisher1997]

Problem

The App struct in src/game/app.zig (lines 38-81) has grown to 40+ fields and violates the Single Responsibility Principle. It currently manages:

• RHI/Rendering systems
• Audio system
• UI system
• Settings management
• Screen management
• Input handling
• Multiple render passes

This makes the struct difficult to maintain, test, and understand.

Current State

The App struct contains 40+ fields mixing rendering, audio, UI, settings, and game state concerns.

Proposed Solution

Extract cohesive subsystems into separate manager structs:

1. RenderSystem - Manages RHI, render graph, render passes, shaders
2. AudioSystemManager - Wraps audio system initialization/lifecycle
3. UISystemManager - Manages UI system, timing overlay
4. SettingsManager - Handles settings persistence and application
5. ScreenSystem - Manages screen manager and transitions

Benefits

• Improved testability (can test managers in isolation)
• Reduced cognitive load (smaller, focused structs)
• Better adherence to SRP
• Easier to mock for testing

Acceptance Criteria

• Create RenderSystem struct to manage rendering concerns
• Create SettingsManager for settings persistence
• Reduce App struct field count by at least 50%
• All existing functionality preserved
• Tests still pass

Related Files

• src/game/app.zig
• src/game/screen.zig (may need updates)

SOLID Principle

Single Responsibility Principle (SRP)

[opencode-agent]

Looking at this issue, I can see this is a well-structured refactoring request to address the God Object anti-pattern in the App struct.

Classification: Refactoring/Architecture Improvement (adhering to SRP)

Analysis:

The issue correctly identifies a maintainability problem. The App struct with 40+ fields violates SRP and makes testing difficult. The proposed solution of extracting subsystem managers is architecturally sound.

Scope Assessment:

While this involves multiple subsystems, they are cohesive (all part of App lifecycle management). However, I recommend considering whether this should be broken into smaller incremental PRs:

1. Phase 1: Extract SettingsManager (low risk, mostly data)
2. Phase 2: Extract AudioSystemManager (self-contained)
3. Phase 3: Extract UISystemManager (moderate complexity)
4. Phase 4: Extract RenderSystem (highest complexity, touches render passes)

Implementation Notes:

• Ensure each manager follows an init/deinit pattern consistent with Zig conventions
• Consider using dependency injection for manager dependencies
• The render system extraction will be the most complex as it manages multiple render passes and RHI interactions
• Each manager should own its own state and expose a minimal public API

Recommendation:

Proceed with this refactoring. The acceptance criteria are clear and measurable. Consider implementing in phases to make review easier and reduce regression risk.

Would you like me to proceed with this refactoring?

opencode session  |  github run