Context and Strategy Interfaces in the Strategy Pattern

A strong Strategy design depends less on the pattern name and more on the boundary between the context and the strategy contract.

The Context

The context should own:

• stable workflow
• non-variable dependencies
• orchestration steps that do not belong to the algorithm choice itself

The Strategy Contract

The strategy contract should expose only what the algorithm needs. If the strategy takes the entire context object just for convenience, coupling starts creeping back in.

Bad boundary:

• strategy receives a giant service or context and cherry-picks fields

Better boundary:

• strategy receives a narrow input model or purpose-built parameters

Review Rule

Keep the strategy interface small and keep the context responsible for everything that is not truly variable.