DEV Community

Design Patterns - Strategy Pattern in JavaScript

Carlos Caballero on February 22, 2019

There are 23 classical design patterns which was described in the original book, Design Patterns: Elements of Reusable Object-Oriented Software. Th...
Read full post
Collapse
 
jessekphillips profile image
Jesse Phillips •

I don't see the original switch statement going away here. By the end of it all you had a list of strategies and a need to determine which one to use, in the case of the final example you executed all strategies which easily could have been done without the switch statement.

Collapse
 
askerovtamerlan profile image
askerovtamerlan •

code below switch statement maybe alternative high-abstract implementation of switch

Collapse
 
carlillo profile image
Carlos Caballero •

Perfect!

Thanks.

Collapse
 
suchcodemuchwow profile image
Meme Oriented Programmer •

Pretty tiring, boring, unnecessary fancy words for js world.

const strategyA = {
  run : function () {} 
}
...

const strategies = {
 strategyA,
 strategyB,
 ...
}

// below string should be a variable to make it more dynamic. 
// And can be wrapped with try/catch if not exist will throw error
strategies['strategyA'].run()
Enter fullscreen mode Exit fullscreen mode
Collapse
 
noleynarbar profile image
Nolan Geiger •

As a former academic, in another field, this article reminded me of when I couldn't explain something to a 12-year-old. I'm new to design-patterns, and have avoided them, but form what I understand, batuxd, the strategy-pattern is simply when one should encapsulate (or store and make accessible for later use) what varies.

Collapse
 
carlillo profile image
Carlos Caballero •

Thanks! 🙃

Collapse
 
onexdata profile image
Nick Steele • • Edited

This looks like it only covers older object-oriented style strategy implementations. This doesn't really do the strategy pattern justice in 2020.

Here is a set of functions on an object, and each object has a process functor that does something different. This object is the core of an analytics engine and replaces many hundreds of lines of code and is very extensible:

const events = {
'heartBeat': { id: 0, process: (e) => ({}) },
'mediatimeupdate': { id: 1, ignore: true, process: (e) => e },
'mediaplay': { id: 8, process: (e) => ({ t: e.detail.plyr.currentTime }) },
'mediaplaying': { id: 9, process: (e) => ({ t: e.detail.plyr.currentTime }) },
'touch': { id: 13, update: 'lookingAt', process: (e) => ({ x: e.x, y: e.y }) },
'focus': { id: 14, update: 'lookingAt', process: (e) => ({ x: e.x, y: e.y }) },
'cartAdd': { id: 19, process: (e) => ({ p: e.id }) },
'cartUpdateQty': { id: 20, process: (e) => ({ p: e.thing.id, q: e.qty }) },
'cartClear': { id: 21, process: (e) => ({}) },
}

Now that you have an object of strategies, you create a 1-line dispatcher for the aspect of event processing...

// Here is the actual "strategy" pattern in this design, the way of calling things based on what is being asked for, the "switchboard" that handles routing to different code based on needs...
const $event = (name, payload, stream = defaultStream) => stream(event[name].process(payload))

Now you can pass in any browser or custom event, and it will process it and pull out only the parts you're looking for, and pass that into any stream you're looking for...

this.$event('cartAdd', thing)

...all this was done with the absolute minimum amount of code possible, and it's incredibly powerful, pushing all the code into a single object of functions, and the dispatches become join points on a cross-cutting concern of "events", and events can contain any payload; their processors are all defined in the same place. Every time you see an $event call in your code, you know you are simply dispatching the event itself. Nothing left to do.

This type of use of the strategy pattern elevates your code from OOP to AOP and cuts your LOC drastically and makes things much easier to understand with zero repetition.

Collapse
 
blixit profile image
Blixit •

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();
}

Collapse
 
askerovtamerlan profile image
askerovtamerlan •

Maybe you know something about implementation of reactivity across strategy design pattern? i'm looking information to create craiglist-mimic-site.

Collapse
 
noleynarbar profile image
Nolan Geiger •

Chego?

Collapse
 
yehanny profile image
Yehanny Olivares •

Hey this content it's awesome thanks for the clarification using Strategy Pattern with JavaScript.

PD: I think someone else copied this content that you should review medium.com/@luiscelismx/implementi...

Collapse
 
estebanappdirect profile image
estebanappdirect • • Edited

Hi, I got this error "ReferenceError: Engine is not defined" may you can help me? thanks
dev-to-uploads.s3.amazonaws.com/i/...

Collapse
 
rmohcie profile image
MoroChev •

Thanks a lot Mr Carlos that's really helpful