Add ADR-0001: Calculator Factory Pattern from PR #181

[Copilot]

Documents the architecture decision to introduce CalculatorBase and CalculatorFactoryBase classes, separating calculator creation from state management as proposed in draft PR #181.

Structure

• docs/adr/README.md - ADR index and format explanation
• docs/adr/0001-calculator-factory-pattern.md - Complete decision record following MADR format

ADR Content

Context: Legacy InterfaceFactoryTemplate couples calculator creation with state management, inconsistent with other EasyScience factories (e.g., minimizers)

Decision: Introduce stateless factory pattern with three components:

• CalculatorBase - Abstract calculator interface with calculate(), model/instrumental parameter management
• CalculatorFactoryBase - Abstract factory with dynamic calculator discovery via _try_register_calculator()
• SimpleCalculatorFactory - Concrete dictionary-based registry implementation

Deprecation: InterfaceFactoryTemplate marked deprecated with migration path documented

Additional: Map._store → Map.__store for proper encapsulation

Migration Example

# Before
class MyFactory(InterfaceFactoryTemplate):
    def __init__(self):
        super().__init__([BackendA, BackendB])

# After
class MyFactory(SimpleCalculatorFactory):
    def __init__(self):
        super().__init__()
        self._try_register_calculator('backend_a', 'pkg.backend_a', 'BackendA')
        self._try_register_calculator('backend_b', 'pkg.backend_b', 'BackendB')

calculator = factory.create('backend_a', model, instrument)

References

• Discussion #160 - Original architecture discussion
• PR #181 - Implementation

Original prompt

Create an ADR proposal based on this draft pull request

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.