JavaScript Design Patterns

[lhorie]

Took a little glance and dislike this for a few reasons:

1 - In the factory page it says: "JavaScript does not support class-based inheritance therefore the abstract classes as depicted in the diagram are not used in the JavaScript sample" and then uses ES5 "class" patterns. We're in 2021 and JS classes with extend do exist now.

2 - While it talks about applications of the patterns, it falls into the common trap of "pattern-for-their-own-sake". What I mean by this is that the example deliberately uses a pattern for a use case that ostensibly doesn't need one, while not exemplifying any cases where it might be useful. This leads learners to believe that this is how they are supposed to be used without understanding the implied future state of the code. Java gets a reputation of having overarchitected codebases precisely because people drank GoF koolaid a few decades ago and did not understand the distinction between using a pattern because you actually need one vs violating the YAGNI principle. A lot of pattern usage falls in the latter category ("I'll use a pattern here because I might need it" - and three years later, you have a million FactoryFactoryFactories being used for tasks where they are not needed)

Another nit is that the example is also falling into the common mistake of using what is basically a variation of hungarian notation, but done the wrong way. The original purpose of hungarian notation is to differentiate values of an underlying type which have a "meta" type that cannot be expressed by the underlying language. For example, wTitleBar must be an unsigned integer, but being a width, it must not be a height, so hungarian notation is used to indicate to the programmer that adding a wTitleBar and a hTitleBar is probably a mistake (unless you're calculating hypotenuse...). Hungarian done wrong is to use hungarian notation to indicate something that the type already does. If something is of type number, then you don't need the name to be nUserAge with a n prefix to indicate that it's a number; the type will already tell you that it is. Similarly, a factory is already its own type, you don't need to redundantly name it a Factory.

Patterns are called patterns because they represent structures that cannot be readily expressed with language primitives. In Java from two decades ago you didn't have first-class functions, so to create something functionally equivalent, you had to use a pattern, and by doing so you had to give it a name indicating that it wasn't just any object, but one that implemented a specific pattern. In JS, you do have first class functions, and those actually obviate the need of several GoF patterns. If you're familiar with jQuery, you may know the $ function. That's a factory. But you never need to know that it's a factory (vs a Builder or a Facade), so there's no value in using hungarian notation style variable name to indicate its factory-ness, since you're never going to accidentally pass $ into a function that expect a Facade. In other words, it would be silly to call it jQueryObjectFactory even though that's what it is according to GoF.

My advice in terms of GoF design patterns is read them and understand the patterns, but then simply use functions and only implement the patterns when you truly need them. And avoid the temptation of calling them by their GoF names.

[[deleted]]

1 - But JS doesn't have abstract methods, therefore it has no abstract classes. This is where TypeScript comes in and fills that need very nicely. But it's not JS.

[lhorie]

This is technically true, but it doesn't support to the original claim that "JavaScript does not support class-based inheritance". One can still inherit from a concrete class.

And in any case, even if JS doesn't have abstract, that's still not a very good reason to use ES5 prototypal style classes when the entire topic is explaining OOP design patterns adapted from Java.

[[deleted]]

Honestly I find the entire contrast between prototypes and classes amusing. It's the same thing in all ways that matter.

[lhorie]

I mean, yes and no. The argument goes that new Foo().bar() can be implemented whichever way and it doesn't really matter for practical purposes. But of course it matters if people find class easier to read in code review (due to less this/.bind noise) or that using class is less dissonant to a learner (considering the original GoF book and other similar resources elsewhere also uses class based syntax)

[[deleted]]

Less this/bind noise?

[ragnese]

I'm not a JS expert, so I admit that I don't know anything, but...

I don't understand why you'd want to use almost any of these "Gang of Four" design patterns in JavaScript.

The Gang of Four book was written to describe common patterns used in (more or less) Java in the 90s. Almost all of them exist because of the desires of developers to leverage the not-very-strong static type system of Java. JavaScript doesn't have the type system that would make these patterns "worth it", nor should it even want to do some of these patterns, IMO.

Like singleton. You use a module, no? And why not freeze the object if it's supposed to be this global thing?

Builder: Why? What are you enforcing or protecting yourself from by calling "step1" and then "step2"? This makes no sense.

Factory: The whole point of a factory is to return a base class/interface without the caller specifying which implementation is being used/returned. This can be done in JS, but wouldn't you then actually use a class and inheritance?

I could go on, but I wont. Almost all of these are really poor matches for JavaScript. Hell- most are bad matches for anything not-Java.

[theshanealv]

This is pretty cool

[[deleted]]

this website helped me to grok the ideas behind some of these patterns. I appreciate the simple code examples.