Overview
Implement a trait-based message system for the UserOutput module to achieve true extensibility following the Open/Closed Principle. This allows new message types to be added without modifying existing code by having each message type encapsulate its own formatting, verbosity requirements, and channel routing logic.
Current State: The codebase already has Theme support (Issue #124) and VerbosityFilter (Issue #103) implemented, providing the foundation for this refactoring.
Specification
See detailed specification: docs/issues/127-use-message-trait-for-extensibility.md
(Link will be updated after issue number assignment and file rename)
🏗️ Architecture Requirements
DDD Layer: Presentation
Module Path: src/presentation/user_output.rs
Pattern: Trait-based polymorphism with concrete message types
Key Changes
- Define
OutputMessage trait with methods: format(), required_verbosity(), channel()
- Implement concrete message types:
ProgressMessage, SuccessMessage, ErrorMessage, ResultMessage, StepsMessage, WarningMessage
- Add
write(&mut self, message: &dyn OutputMessage) method to UserOutput
- Refactor convenience methods to use trait dispatch
Implementation Plan
Phase 1: Define Core Trait and Types (2 hours)
Phase 2: Implement Concrete Message Types (3 hours)
Phase 3: Refactor UserOutput (2.5 hours)
Phase 4: Testing and Validation (2 hours)
Phase 5: Documentation and Cleanup (1 hour)
Estimated Total Time: ~11 hours
Acceptance Criteria
Quality Checks:
Task-Specific Criteria:
Related
Benefits
✅ True Open/Closed Principle - add new message types without touching existing code
✅ Encapsulation - each message knows how to format itself
✅ Single Responsibility - each message type has one clear purpose
✅ Testability - message types can be tested independently
✅ Extensibility - custom message types can be defined outside the module
Overview
Implement a trait-based message system for the
UserOutputmodule to achieve true extensibility following the Open/Closed Principle. This allows new message types to be added without modifying existing code by having each message type encapsulate its own formatting, verbosity requirements, and channel routing logic.Current State: The codebase already has
Themesupport (Issue #124) andVerbosityFilter(Issue #103) implemented, providing the foundation for this refactoring.Specification
See detailed specification: docs/issues/127-use-message-trait-for-extensibility.md
(Link will be updated after issue number assignment and file rename)
🏗️ Architecture Requirements
DDD Layer: Presentation
Module Path:
src/presentation/user_output.rsPattern: Trait-based polymorphism with concrete message types
Key Changes
OutputMessagetrait with methods:format(),required_verbosity(),channel()ProgressMessage,SuccessMessage,ErrorMessage,ResultMessage,StepsMessage,WarningMessagewrite(&mut self, message: &dyn OutputMessage)method toUserOutputImplementation Plan
Phase 1: Define Core Trait and Types (2 hours)
OutputMessagetrait andChannelenumPhase 2: Implement Concrete Message Types (3 hours)
Phase 3: Refactor UserOutput (2.5 hours)
write()methodPhase 4: Testing and Validation (2 hours)
Phase 5: Documentation and Cleanup (1 hour)
Estimated Total Time: ~11 hours
Acceptance Criteria
Quality Checks:
./scripts/pre-commit.shTask-Specific Criteria:
OutputMessagetrait is defined with all required methodsUserOutputhas a genericwrite()method that accepts trait objectsUserOutputstructRelated
Benefits
✅ True Open/Closed Principle - add new message types without touching existing code
✅ Encapsulation - each message knows how to format itself
✅ Single Responsibility - each message type has one clear purpose
✅ Testability - message types can be tested independently
✅ Extensibility - custom message types can be defined outside the module