I can just hear all the OOP gurus screaming internally "JUST USE A CLASS" lol.
For real though, what you created (closure) is just shorthand class mechanisms with a private property without the extra OOP handling. It makes sense, and when you think about it, this is extremely similar to how react handles state.
As complexity grows, you may find a need to reset that flag, which then leads into do you return an object with multiple properties (functions/methods) with a reset action, or do you create a class? These are edge cases that mutate the original intent but it's like Taco Bell here in engineering: Most algorithms and mechanisms are using all the same ingredients, just reshaped slightly different and given a different name.
Closures are a good pattern to implement, but with too much investment into a closure, as complexity grows, you may find that you need a different, or a more robust solution.
I can just hear all the OOP gurus screaming internally "JUST USE A CLASS" lol.
For real though, what you created (closure) is just shorthand class mechanisms with a private property without the extra OOP handling. It makes sense, and when you think about it, this is extremely similar to how react handles state.
As complexity grows, you may find a need to reset that flag, which then leads into do you return an object with multiple properties (functions/methods) with a reset action, or do you create a class? These are edge cases that mutate the original intent but it's like Taco Bell here in engineering: Most algorithms and mechanisms are using all the same ingredients, just reshaped slightly different and given a different name.
Closures are a good pattern to implement, but with too much investment into a closure, as complexity grows, you may find that you need a different, or a more robust solution.
Wow! That was insightful, I never considered OOPs perspective