The cost that come alongside these particular patterns should also be noted before carelessly using them. There's a certainly a lot of usability to be gained through using them, but the costs must be weighed in. Something that I don't see a lot of people doing.
The singleton pattern is the most at blame here. A pattern, whose entire premise revolves around global state, is potentially dangerous. As a industry, we've seen the major headaches caused by global state over the course of multiple decades - and I don't think I even have to explain them. As we move forward, we're trying to minimize global state for the better. But the singleton pattern seems to not get enough attention from this standpoint. And, don't get me wrong, there's a lot of attention. But the simple fact that many people are still being taught to use it without care.....should really say something.
Instead, Avoid hiding a logical dependency behind global state. In many, many cases - there's a way to simply use an explicit parameter. This is not to say that there is absolutely zero scenarios where they aren't your only choice though. In fact, a global constant binding to some object/struct/value - is perfectly fine.
The factory pattern, on the other hand, is.....weird. It's a "pattern" that aims to solve a problem that shouldn't exist in the first place. What is so hard about higher order functions? Was it really that difficult to implement half a century old concept in Java (I talk about Java here since that's the primary culprit behind the current widespread usage of this specific pattern)? Even C has the ability to use functions as data, what was so hard?
Regardless, it exists. And it's entire premise is to create a "function" depending on some configuration (arguments). Then, when that created "function" is called, it spits out some data value (termed "object" in this case) corresponding to the configuration. Why do we need a crap ton of boilerplate for this? This is a singular function, taking some arguments, and returning another function. Throw in a strong type system, and maybe currying, and wallah! you've achieved, in 5 lines, what a "pattern" would take you 50. Can we really call this a "pattern"?
In any case, my point is, while both of these patterns arguably have their uses - the alternatives should be considered.
This post on dev.to itself is a neat little brief opener on the alternatives. Generally using FP concepts, but most of it really just boils down to higher order functions. So it should apply to JS/TS regardless. Though I must say the title is slightly misleading, but not in a predatory way. Full on pure FP langs, after all, still have a few of their own design patterns - FP doesn't eliminate the need for patterns.
After that briefer, this SO post sums up the correspondences between the GoF patterns and functional alternatives very well. But unfortunately, it never goes on to detail them too much :( - (possibly because every alternative is just a function?)
And lastly, this talkdoes go into some detail about exactly how to implement the alternatives. It also sums up the alternatives in a single slide! Around 3:20 minute mark. Though this one assumes some core functional concepts like currying. Thankfully, emulating currying is very simple when you have.....you guessed it! - higher order functions. JS/TS can do that. (ok that's not fully true, you also need closures but JS/TS has that too)
The cost that come alongside these particular patterns should also be noted before carelessly using them. There's a certainly a lot of usability to be gained through using them, but the costs must be weighed in. Something that I don't see a lot of people doing.
The singleton pattern is the most at blame here. A pattern, whose entire premise revolves around global state, is potentially dangerous. As a industry, we've seen the major headaches caused by global state over the course of multiple decades - and I don't think I even have to explain them. As we move forward, we're trying to minimize global state for the better. But the singleton pattern seems to not get enough attention from this standpoint. And, don't get me wrong, there's a lot of attention. But the simple fact that many people are still being taught to use it without care.....should really say something.
Instead, Avoid hiding a logical dependency behind global state. In many, many cases - there's a way to simply use an explicit parameter. This is not to say that there is absolutely zero scenarios where they aren't your only choice though. In fact, a global constant binding to some object/struct/value - is perfectly fine.
The factory pattern, on the other hand, is.....weird. It's a "pattern" that aims to solve a problem that shouldn't exist in the first place. What is so hard about higher order functions? Was it really that difficult to implement half a century old concept in Java (I talk about Java here since that's the primary culprit behind the current widespread usage of this specific pattern)? Even C has the ability to use functions as data, what was so hard?
Regardless, it exists. And it's entire premise is to create a "function" depending on some configuration (arguments). Then, when that created "function" is called, it spits out some data value (termed "object" in this case) corresponding to the configuration. Why do we need a crap ton of boilerplate for this? This is a singular function, taking some arguments, and returning another function. Throw in a strong type system, and maybe currying, and wallah! you've achieved, in 5 lines, what a "pattern" would take you 50. Can we really call this a "pattern"?
In any case, my point is, while both of these patterns arguably have their uses - the alternatives should be considered.
Fair point! Thank you for the feedback @totally_chase .
If you develop / showcase the alternative in a blog post let me know, that would be interesting!
This post on dev.to itself is a neat little brief opener on the alternatives. Generally using FP concepts, but most of it really just boils down to higher order functions. So it should apply to JS/TS regardless. Though I must say the title is slightly misleading, but not in a predatory way. Full on pure FP langs, after all, still have a few of their own design patterns - FP doesn't eliminate the need for patterns.
After that briefer, this SO post sums up the correspondences between the GoF patterns and functional alternatives very well. But unfortunately, it never goes on to detail them too much :( - (possibly because every alternative is just a function?)
And lastly, this talk does go into some detail about exactly how to implement the alternatives. It also sums up the alternatives in a single slide! Around 3:20 minute mark. Though this one assumes some core functional concepts like currying. Thankfully, emulating currying is very simple when you have.....you guessed it! - higher order functions. JS/TS can do that. (ok that's not fully true, you also need closures but JS/TS has that too)
Awesome thanks for all the resources 💪