Decouple DefaultContext from concrete simulation classes via factory pattern

[Copilot]

DefaultContext directly instantiated Generator and InOutWorker, violating dependency inversion and making the code difficult to test or extend for the planned jDisco→DSOL migration.

Changes

Factory abstraction:

• SimulationProcessFactory interface in context package defines process creation contract
• DefaultSimulationProcessFactory in sim package provides concrete implementation
• Factory injected via Koin DI into contexts needing simulation capabilities

DefaultContext refactoring:

• Accepts SimulationProcessFactory via constructor
• Delegates process creation to factory instead of direct instantiation
• Removed Generator import; setMainProcess() now accepts LoopProcess base type

Example:

// Before: Direct dependency
if (mainProcess == null) mainProcess = Generator(this)

// After: Factory abstraction
if (mainProcess == null) {
    mainProcess = processFactory.createMainProcess(this)
}

Benefits:

• Testable with mock factories
• Simulation engine swap requires only factory replacement
• Context package no longer couples to concrete sim/ implementations

Testing:

• Unit tests verify factory injection and process creation
• Full integration validation pending CI (requires jDisco GitHub Packages auth)

Future work:
Phase 3 (separate PR): Split into DefaultEditingContext and DefaultSimulationContext classes for complete separation of concerns per issue comments.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Divide DefaultContext to Editing and Simulation implementation using factories or DI and some new classes</issue_title>
<issue_description>DefaultContext directly instantiates simulation process classes, violating dependency inversion and creating tight coupling to the sim/ package.

Problematic code

// context/DefaultContext.kt imports:
import cz.vutbr.fit.interlockSim.sim.Generator
import cz.vutbr.fit.interlockSim.sim.InOutWorker
import cz.vutbr.fit.interlockSim.sim.ShuntingLoop

// Later in code:
val generator = Generator(...)
val worker = InOutWorker(...)

Impact

• Context depends on concrete simulation classes (should depend on abstractions)
• Cannot test context without simulation classes
• Violates single responsibility principle
• Makes it difficult to add new simulation types

Recommended Solutions

1. Factory pattern: Create SimulationProcessFactory interface with implementations
2. Extend Koin DI: Define simulation objects in Koin modules (but see constraints below)
3. Strategy pattern: Abstract simulation setup logic

Constraints

• Per CLAUDE.md: sim/ package is RESTRICTED (jDisco migration pending)
• Must coordinate with future jDisco → DSOL/Kalasim migration
• Cannot add Koin to sim/ package yet (traffic-simulation-expert requirement)

Complexity: MEDIUM-HIGH - Requires careful design to align with jDisco migration strategy

Priority: Medium - Improves testability but doesn't block current work

Acceptance Criteria

• DefaultContext does not import concrete sim/ classes
• Simulation object creation uses factory abstraction or DI
• All 662 tests pass (especially simulation tests)
• Design documented and compatible with future DSOL migration</issue_description>

<agent_instructions>implement all phases - follow the comments carefuly </agent_instructions>

Comments on the Issue (you are @copilot in this section)

@bedaHovorka Editing and simulation context must be divided:

• editation context: mutable net, new parts are added, removed. Parts are inside immutable. Create new instead update inside.
• simulation context: net is immutable. But parts has some dynamic properties in additon.

Simulation and and editation must be more independent on UI.

Thanks to DI by Coin we can divide it better. Use design patterns etc.</comment_new>
<comment_new>@bedaHovorka
Simulation and editing model classes should be different. But for first refactor can be sufficient smaller changes.

My proposal:

For each RailSemaphore, RailSwitch, InOut, ..., Track(Block):

• must contain only "static" properties (static from point of view of simulation, not programming ;)
• must exist some Dynamic* class for dynamic properties (which is changing during simulation)
• this dynamic class should be at first linked with its stattic instance by delegation (kotlin delegation?)
• this delegate is stable base for compute equals and hashcode to be Dynamic* placed in some net</comment_new>
  <comment_new>@bedaHovorka
  @claude : what do you think about my proposal in previous comments?</comment_new>
  <comment_new>@bedaHovorka
  We can break some constrains in sim if behaviour and physics will be kept.</comment_new>
  <comment_new>@bedaHovorka
  @claude : draft the detailed design document please at the moment</comment_new>
  <comment_new>@bedaHovorka
  => DefaultContext should get by this refactor as DefaultEditingContext (without simulation things)</comment_new>

• Fixes Divide DefaultContext to Editing and Simulation implementation using factories or DI and some new classes #92

---

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

[Copilot]

Pull request overview

This PR implements the Factory pattern with Dependency Injection to decouple DefaultContext from concrete simulation classes (Generator, InOutWorker), addressing SOLID principle violations. This is Phase 2 of a larger refactoring effort; Phase 3 will split DefaultContext into separate DefaultEditingContext and DefaultSimulationContext classes.

Changes:

• Introduced SimulationProcessFactory interface to abstract simulation process creation
• Implemented DefaultSimulationProcessFactory as the concrete factory for jDisco-based processes
• Refactored DefaultContext to accept factory via constructor and delegate process creation
• Updated XMLContextFactory to inject and pass the factory to contexts
• Configured Koin DI to provide SimulationProcessFactory singleton
• Added comprehensive unit tests and documentation

Reviewed changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
SimulationProcessFactory.kt	Factory interface defining process creation contract in context package
DefaultSimulationProcessFactory.kt	Concrete factory implementation in sim package creating Generator and InOutWorker instances
DefaultContext.kt	Refactored to use injected factory instead of direct instantiation; signature change from ShuntingLoop to LoopProcess
XMLContextFactory.kt	Injects SimulationProcessFactory from Koin and passes to DefaultContext constructor
InterlockSimModule.kt	Registers SimulationProcessFactory singleton in simulationModule
SimulationProcessFactoryTest.kt	Unit tests verifying factory injection and process creation
CONTEXT_REFACTORING_DESIGN.md	Comprehensive design document (513 lines)
FACTORY_PATTERN_IMPLEMENTATION.md	Implementation summary and migration guide (241 lines)
IMPLEMENTATION_COMPLETE.md	Implementation completion checklist (219 lines)
CLAUDE.md	Updated architecture documentation with factory pattern details

[bedaHovorka]

@claude : what do you thing about all this changes?

[Copilot]

@claude : what do you thing about all this changes?

The factory pattern implementation successfully decouples DefaultContext from concrete simulation classes, addressing the SOLID violations. The code now follows dependency inversion principle - contexts depend on the SimulationProcessFactory abstraction rather than concrete Generator/InOutWorker classes. This makes the code more testable and prepares it for the jDisco→DSOL migration.

The subsequent commits (9c95fc5 and 550e1b8) completed Phases 3 and 4, splitting DefaultContext into DefaultEditingContext and DefaultSimulationContext, and beginning the static/dynamic property separation as you requested in the issue comments.

[Copilot]

Pull request overview

Copilot reviewed 127 out of 135 changed files in this pull request and generated no new comments.

[sonarqubecloud]

Quality Gate failed

Failed conditions
58.2% Coverage on New Code (required ≥ 80%)
C Reliability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE