Thanks for sharing your insights. I am not so found of the Module Design Pattern.
I think no-one should be opinionated about programming styles. Programming paradigms are tools, and as tools we should use the best one for the job when we see fit.
I like reminding my coworkers that javascript is in fact a prototype based object oriented programming langage with first class functions in it. It is not a pure functional langage like haskell, nor a pure object oriented langage like java used to be.
In Javascript we simply don't have the tools to do clean functionnal programming. And if doing something clean means using classes, you should do it. And in the same way, you should not use classes everywhere, not everything is a class.
Here are things that most functionnal programming langages offer and javascript don't :
expression statements (see tc-39 proposal for do-expressions) => alternative with IIFE
pattern matching (see tc39 proposal for pattern matching) => no clean alternative
pipeline operator ( see tc39 proposal for pipeline operator ) => no clean alternative
advanced monad tools (like do notation, etc, no proposal) => no clean alternative
standard native adt library => we need to use libraries like sanctuary, monet, etc
standard native algorithm library => we need to use libraries like ramda, lodash/fp, etc
So now, what is the issue everybody have with oop ?
From my point of view, the main issue with oop it's that the oop community abused two tools and made oop an over-engineering-fest (the enterprise syndrome):
using design patterns everywhere: singleton, factory, getter/setter boilerplate, abtracted classes
using polymorphism everywhere: making everything come with a hierarchy
On the opposite side, when maintaining big functionnal code bases, the main issues you face is that a lot of real objects (structure) are hidden by behaviour (functions).
React does not face this issue much, because components are the main building blocks of your infrastructure. So react components exposes structure naturally. And react hooks exposes behaviour naturally. And both gives you a nice and elegant balance that emerges naturally in your project (that's why react is awesome).
But in some part of your code that does not use react, identifying what your main building blocks are can be difficult and lead to bad designed functionnal code with functions-spagetti-fest. This is a big issue for maintenance. In some cases, using a class might be a good idea to make this code maintainable.
Now about why i don't like Module Design Pattern : No matter what some oop haters think, this is oop. Indeed, if what you are doing is, have an object instanciated by passing some parameters (it's obviously a constructor) and then calling functions to control the object (it's obviously a method), you are doing object oriented programming.
If some people really prefer writing boilerplate code to address the private field and method issue Javascript have right now... i would suggest them to use a babel transpiler and use tc39 private fields proposal. it's much more clean than using MDP.
First, I wanted to thank you for taking the time to write out this thoughtful reply. And for the most part, I agree with you. But I can't really write too much more here that explains my thoughts on the matter because my responses to Maciej Sikora in this same comment section pretty much highlight why I've moved to this design pattern for the time being. Part of it, quite frankly, is just a matter of practicality on my part. (React is pretty-much already in this pattern - and I write a ton of React.) Part of it is exhaustion. (If I can write code in Style A or Style B, and I personally like both styles equally, then I might just veer toward the one that inspires less whining from the fanboys.)
But again, I agree with your points and I totally appreciate the thoughtful feedback!
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.
Hi Adam,
Thanks for sharing your insights. I am not so found of the Module Design Pattern.
I think no-one should be opinionated about programming styles. Programming paradigms are tools, and as tools we should use the best one for the job when we see fit.
I like reminding my coworkers that javascript is in fact a prototype based object oriented programming langage with first class functions in it. It is not a pure functional langage like haskell, nor a pure object oriented langage like java used to be.
In Javascript we simply don't have the tools to do clean functionnal programming. And if doing something clean means using classes, you should do it. And in the same way, you should not use classes everywhere, not everything is a class.
Here are things that most functionnal programming langages offer and javascript don't :
So now, what is the issue everybody have with oop ?
From my point of view, the main issue with oop it's that the oop community abused two tools and made oop an over-engineering-fest (the enterprise syndrome):
On the opposite side, when maintaining big functionnal code bases, the main issues you face is that a lot of real objects (structure) are hidden by behaviour (functions).
React does not face this issue much, because components are the main building blocks of your infrastructure. So react components exposes structure naturally. And react hooks exposes behaviour naturally. And both gives you a nice and elegant balance that emerges naturally in your project (that's why react is awesome).
But in some part of your code that does not use react, identifying what your main building blocks are can be difficult and lead to bad designed functionnal code with functions-spagetti-fest. This is a big issue for maintenance. In some cases, using a class might be a good idea to make this code maintainable.
Now about why i don't like Module Design Pattern : No matter what some oop haters think, this is oop. Indeed, if what you are doing is, have an object instanciated by passing some parameters (it's obviously a constructor) and then calling functions to control the object (it's obviously a method), you are doing object oriented programming.
If some people really prefer writing boilerplate code to address the private field and method issue Javascript have right now... i would suggest them to use a babel transpiler and use tc39 private fields proposal. it's much more clean than using MDP.
First, I wanted to thank you for taking the time to write out this thoughtful reply. And for the most part, I agree with you. But I can't really write too much more here that explains my thoughts on the matter because my responses to Maciej Sikora in this same comment section pretty much highlight why I've moved to this design pattern for the time being. Part of it, quite frankly, is just a matter of practicality on my part. (React is pretty-much already in this pattern - and I write a ton of React.) Part of it is exhaustion. (If I can write code in Style A or Style B, and I personally like both styles equally, then I might just veer toward the one that inspires less whining from the fanboys.)
But again, I agree with your points and I totally appreciate the thoughtful feedback!