Remove State Machine Information from SPI

[DominikPinsel]

As discussed here the proposal to remove information about the state machines from the SPI. I think in general, every time we have the possibility to remove something from the SPI without losing any functionality we should do so, to keep the size of the SPI to a minimum.

State Machine Refactoring

Disclaimer: I will call parts of the algorithm, that execute a step that is necessary to advance the process to the next state, sub-routines.

Assumed Issues

• Algorithm/State Machine should not be known to subroutines / the SPI.
• Algorithm/State Machine should call sub-routines synchronous and handle asynchronism itself.
• Value object, that is passed to the sub-routines, must be immutable.
• Sub-routines should share common interface

Why is this an improvement

• If the algorithm/state machine is implemented by many extensions, it
  • is difficult to test.
  • may affect the consistency of the algorithm, as extensions may implement the same part of the algorithm differently.
  • increases complexity.
• If the algorithm/state machine doesn’t handle synchronism itself
  • it must be handled by each sub-routined, which
    • may be inconsistently handled.
    • may lead to side effects in the algorithm.
• If value objects, that are passed to the sub-routines, were not immutable
  • sub-routines would be able to affect the algorithm directly, which
    • increases complexity.
    • may lead to unexpected side effect.
• If sub-routines don’t share a common interface
  • they must all be handled differently, which
    • increases complexity.
    • violates the Open-Close Principle.
• If the state machine is part of the SPI
  • the size of the SPI increases, which
    • increases complexity of EDC.
    • increases difficulty to develop extensions.

Proposal

• States removed from SPI
• New immutable object that contains information about the algorithm and is not shared with sub-routines
• New immutable object with subject information that is passes to the sub-routines
• Centralized algorithm that manages state changes and asynchronism
• All sub-routines are moved to their own class
• All sub-routines share a common interface

Nice Takeaway

• The EDC would be able to support different kinds of algorithms and is not bound to the state machine model.

_{Dominik Pinsel [email protected], Daimler TSS GmbH, legal info/Impressum}