[LOW] Add more interface abstractions - Reduce concrete dependencies throughout codebase

[MichaelFisher1997]

Problem

While the codebase uses interfaces effectively in some areas (IScreen, IChunkProvider, RHI interfaces), many modules still depend on concrete types rather than abstractions. This reduces testability and flexibility.

Examples of Concrete Dependencies

1. World depends on concrete ChunkStorage

World struct uses storage: ChunkStorage (concrete type)

2. Screen implementations depend on concrete systems

Screens import and use World, RHI directly rather than interfaces.

3. App depends on concrete settings modules

App imports settings.zig directly.

Proposed Solution

Gradually introduce more interface abstractions:

Phase 1: Define Interfaces

• IChunkStorage - for chunk storage operations
• IWorld - for world queries (read-only)
• IMutableWorld - for world modifications
• ISettings - for settings access

Phase 2: Update Callers

Refactor modules to depend on interfaces instead of concrete types.

Benefits

• Improved testability (can use mock implementations)
• Reduced coupling between modules
• Easier to swap implementations
• Better adherence to Dependency Inversion Principle

Acceptance Criteria

• Define IChunkStorage interface
• Define IWorld interface
• Update at least 3 screen implementations to use interfaces
• Create mock implementations for testing
• All tests pass

Non-Goals

• Don't convert everything at once (gradual migration)
• Don't add interfaces where they don't provide value

Related Files

• src/engine/core/interfaces.zig
• src/world/world.zig
• src/world/chunk_storage.zig
• src/game/screens/*.zig

SOLID Principle

Dependency Inversion Principle (DIP)

Estimated Effort

Low (incremental work over time)

[opencode-agent]

Looking at this issue, I can see it's a well-structured refactoring request focused on improving code quality through better abstractions.

Classification: Code Improvement / Refactoring (Feature Request)

Analysis: This is a thoughtfully scoped issue that follows good practices:

• Phased approach minimizes risk
• Clear acceptance criteria
• Explicit non-goals prevent scope creep
• Focuses on testability and DIP

The examples provided are concrete and actionable. The gradual migration strategy is smart—interfaces should be introduced where they provide value, not everywhere.

Implementation Suggestions:

1. Start with IChunkStorage since World → ChunkStorage is a clear dependency to break
2. Consider interface composition - IMutableWorld could embed IWorld to avoid duplication
3. For testing, you might want to look at how existing interfaces like IScreen and IChunkProvider are mocked in tests
4. Zig-specific: Use anytype or vtable patterns depending on whether you need runtime polymorphism or compile-time dispatch

A few questions to consider:

• Should these interfaces use error unions consistently?
• For ISettings, consider if you need read-only (ISettings) vs mutable (IMutableSettings) variants
• Would it make sense to add these interfaces incrementally per-PR rather than one large PR?

This is definitely worth doing. The testability benefits alone justify the effort, especially as the codebase grows. The acceptance criteria are well-defined and achievable.

Verdict: Good to proceed. The scope is appropriate and the phased approach is practical.

opencode session  |  github run