Mastering JavaScript Design Patterns (MJDP) is another book Packt graciously sent me. This book is divided in two parts. The first part is about Gang Of Four (GoF) classical Design Patterns the other part is about other well know patterns.

TL;DR: Overall the book is good enough and will be perfect for developers with little experience in software development.

However be careful with the following points below:

• UML diagrams are not descriptive as they should be, "memberName" should not be written multiple times as class attributes
• The part where the author said that singleton could not be created in JavaScript in a OOP way is plain wrong
• In the Functional Programming chapter, JavaScript examples could have been written better. Using a for loop instead of map (IE9+) is disappointing (to say the least!)
• The MV* chapter does not follow the Separation of Concerns principle well enough
• View initialization and rendering are done inside the constructor (they should not be)
• Model attributes are too often manipulated inside the controller
• State information is duplicated (e.g. IsValid in ValidationResult)
• A dispose (or release) method is missing for clean life-cycle management
• bind (IE9+) should be used instead of the old _this workaround

As I am currently preparing a lecture on Design Patterns, I started to read the famous Design Patterns: Elements of Reusable Object-Oriented Software a.k.a the Gang of Four book as well as Les design patterns en Java and Mastering JavaScript Design Patterns.

Whether or not Design Patterns in oriented programming language are a language smell is another story (even if I could not personally agree more). I wanted to write about the following affirmations in Mastering JavaScript Design Patterns:

My first reaction  reading this was:
The second check inside the Wall constructor is hideous and we can definitely hide the constructor thanks to a closure, leveraging JavaScript functional nature. I thus gave this affirmation as an exercise for my students and here is a possible solution:


But we can go even further, why bother duplicating singleton logic when you can make a Singleton factory:

Note that the Singleton factory invocation must be alongside the internal implementation otherwise the JavaScript constructor could be instantiated multiple times.

Bonus: a lot of Singleton implementations available on Internet forgot to hide the constructor, even Addy Osmani books on JavaScript Design Patterns forgot this:

PS: The __proto__ trick for hiding the constructor is now widely supported (IE11+).

[Update] Supporting static methods and leveraging Object.create features instead of redefining __proto__.constructor: