Decouple notice format from the selected transport
ReminderEmailProviderA and CancellationEmailProviderA have matching ProviderB subclasses. Adding a third notice type is multiplying classes even though formatting and transport are independent choices.
- Focused work estimate
- 3h + prerequisites
- Priority in the scenario
- Medium
- Engineering practice
- Composition · Capability contracts · Design comparison
Estimated field mix
- Integrations50%
- System design50%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Pattern topics
- BridgeCompare
Separate independently varying notice content and provider transport so their combinations do not require a growing subclass matrix.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
A fictional maintenance scheduler sends appointment notices through two providers. Their request shapes, error codes, and acknowledgement semantics differ. Build two local scripted provider doubles and a TypeScript application module; use synthetic recipients, block external network access, and never send real notifications. No provider accounts, starter repository, or production delivery qualification is supplied.
Setup prerequisites
- HTTP contracts
- Asynchronous cancellation
- Dependency injection
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
Acceptance criteria
- Separate notice-content construction from provider transport, with two notice types runnable through both local providers.
- Document required transport capabilities and reject incompatible content before sending; do not silently drop a cancellation reason.
- Compare a Bridge between notice abstraction and transport with two composed functions, avoiding one subclass for every combination.
Implementation constraints
- Use plain text only in the exercise; user-provided content remains data and is never executed as a template or command.
Verification to include
- Exercise all four type/provider combinations and compare semantic content after adaptation.
- Configure a transport without a required capability and assert rejection before any stub call.
Deliverables
- Independent content/transport composition and capability matrix tests
Rollout and recovery
Replace combination classes after all four fixtures pass; keep the declared provider contract stable while moving formatting code.
Value of the work
For the engineer: Practice placing provider boundaries, comparing wrappers and coordinators, and testing ordering, cancellation, and resource limits under controlled faults.
For the team: Review whether a provider change can be made without rewriting scheduling rules, leaking recipient data, or turning one provider failure into wider exhaustion.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.