Pensando en programar

This question has been sitting here for a while now. I don't really feel any urge to answer it. Meanwhile, I'll use as a placeholder an explanation I gave on reddit about Addy Osmani's book and about other authors that follow his lead on the subject and end up making the same mistakes.

Well, this has been discussed a number of times, but the problem is that it's mostly the whole book. Or almost all of it.

The book starts with a theoretical introduction to DP. What is a Pattern? is a section of that part and a crucial question to ask, of course. And, unfortunately, Osmani fails to give a good answer. A pattern is composed mainly by 3 parts:

  • a problem
  • a context in which the problem occurs
  • a general approach to implement the best solution for the problem

It is extremely important to understand this. Understanding the problem itself is, naturally, essential. It doesn't make sense to apply a solution to a problem it does not apply. It is also equally important to understand the context, because it is the context the one that restricts and defines applicability. The same problem in a different context may simply not occur (e.g. Singletons in Scala are already supported by the language itself, you don't need to implement any solution to achieve that). Finally, it is very important to understand that the third part is not, generally, a precise solution, but an approach to implement such a solution.

Instead, Osmani's explanation fails in two main points (it will fail on the third later; keep reading). First it simply ignores context; context is rarely if ever taken into account in the whole book. This results in applying some foreign patterns without questioning if they are applicable at all. Then it focuses too much on the solution. “Pattens are proven solutions”, and “A pattern usually reflects an out of the box solution”, and similar ideas. He even goes as far as separating the solution from the problem by arguing that they are solutions which “are not tied to a specific problem”.

Even so, not all is bad in that first part. It is true that DP form a common vocabulary we can use to communicate approaches, and the full structure of a DP (including a mention, the only mention, to context) is shown. The worst thing about this part is that it contradicts itself in various ways (probably because of how it was built from collecting and mashing together various existing writings and blog posts). I've seen various people commenting how this part is too long. I don't see that as necessarily a bad thing. I understand the criticism and understand that some people may want to “jump for the meat right away” but I actually think it is good to spend some extra time explaining the concepts first. It's just that it is not a very good explanation.

Then, finally, we get to the patterns themselves. And here the author completely fails to follow his own advice.

He presents a collection of things, some of which may be DP and some of which are clearly not DP at all. In general, he fails in the same way throughout the rest of the book: Most of the time he just jumps into showing some code without either mentioning what the problem is or what the shown approach aims to provide. Again, DP are not pieces of code. And you need to set up both the problem and the context before you try to offer an approach (not a direct out-of-the-box solution).

Not only that, but there's an underlying problem with the patterns presented themselves. As I mentioned, some may be DP, some clearly aren't. It is a collection of some of the original GoF design patterns mindlessly “ported” to JS without care, and a few “new” patterns added by Osmani.

Let's just look at a selected few.

The first one, the so called “Constructor Pattern”. This is absolutely not a design pattern in any sense. It is just a presentation on a number of ways you can create an object in JavaScript. There is no problem to solve here, just a description of the language itself.

Similarly the “Module Pattern” is just an overview of various variants on using closures to achieve some privacy, as implemented in various libraries (some now outdated) such as Dojo, ExtJS or YUI. A companion to this, the “Revealing Module Pattern” is simply writing the previous thing in a slightly different manner (instead of inline functions you just put the reference of the function that is written above). To think that this trivial change makes it a different thing is absurd. This whole section presenting different module structures written by various (some outdated) libraries, is -again- a blog post inserted here without much of a reason to do so.

Following is Singleton. I think I don't need to talk about this one. But in any case it is a typical example of how the whole book goes in general: It completely ignores the change of context. In the original context where Singleton was suggested you just couldn't create objects directly, you always needed to instantiate a class to obtain an object. This is not so in JavaScript (hey, it was shown just a while ago in that “Constructor Pattern” section), but is ignored by the author. It also has a number of additional problems (of various importance):

- It doesn't really explain the approach, just shows some code - The code it shows is bad. Instead of showing a Singleton, he decides it is a good idea to confuse things by directly showing a “good singleton vs bad singleton” as the first thing. The code for the “good singleton vs bad singleton” is unnecessarily complicated and what's more, there are differences between “good” and “bad” which are unrelated to the “goodness” or “badness”. The only meaningful difference is lines 42-44 vs line 79.

Also, the solution presented is rarely the best approach. Let's jump to, say, the Command Pattern. Leaving aside other things (such as the command pattern not being exactly necessary in a language which does support first class functions, as it is, basically, “a polyfill for first-class functions”), the solution presented is a stringly based solution”. This is bad code. Code like this is routinely rejected in professional environments. I mean, if you really wanted to do the Command Pattern in JavaScript, even Wikipedia has a better solution. One that is still unnecessarily complicated, but at least is not stringly-typed (and it uses modern ES6 syntax).

I won't go over the whole book; I think this already exemplifies the general problems that persist throughout the whole of it. There are some other, maybe less important, problems. The thing I commented about just inserting some “interesting” blog post here or there happens a number of times to some extent. He goes on a tangent explaining a more or less related subject for a while. This is not so bad, but it does add to a general poor structure. It's weird, to point out just one example, to casually mention in the explanation of the Singleton how “getInstance becomes a little like a Factory method” assuming some fairly non-trivial knowledge on the subject when Factories aren't presented until much later and Factory Method is only ever mentioned in the explanation in one comment in the code. There's also a lot of inconsistency in the examples. Sometimes a pattern will be presented with, say, an example about hobbits and orcs, then a first example shown is about vehicles and colours, the second example about macbooks and memory sizes, and then the final one is an example on interfaces and to-do-items. This is not terribly bad, I know, but it does not exactly help compare the various parts.

I don't think everything is bad in the book. And the effort spent must be acknowledged. It's just that the result obtained from that effort feels, well… misguided is the best word that describes it. It is an important effort, time was spent writing that, but in the end the result is less than good.