I think there's some misunderstanding about the strategy design pattern which takes advantages from dependency injection and algorithm detection at runtime based on the use case.
// class to use as 'interface' in your dependency injection
class StrategyA {
doAction() {...}
}
// someStrategy can be string (will require a mapping) or class based on your architecture
function myMethod(...) {
// someStrategy, otherArgs: can be injected as parameters
// or come from the current scope
const dynamicAlgorithm = resolveStrategy(someStrategy, otherArgs);
dynamicAlgorithm.doAction();
}
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think there's some misunderstanding about the strategy design pattern which takes advantages from dependency injection and algorithm detection at runtime based on the use case.
// class to use as 'interface' in your dependency injection
class StrategyA {
doAction() {...}
}
// someStrategy can be string (will require a mapping) or class based on your architecture
function myMethod(...) {
// someStrategy, otherArgs: can be injected as parameters
// or come from the current scope
const dynamicAlgorithm = resolveStrategy(someStrategy, otherArgs);
dynamicAlgorithm.doAction();
}