Comments regarding The Module Pattern

[svenheden]

First of all I want to thank you for writing a great book! I'm reading it right now and found a couple of minor semantic issues in the chapter The Module Pattern.

1. The pattern is quite similar to an immediately-invoked functional expression (IIFE - see the section on namespacing patterns for more on this) except that an object is returned rather than a function.

   I don't think the module pattern is similar to an IIFE; it uses an IIFE. And in an IIFE a function isn't necessarily returned, it's invoked. Don't you agree? :)

2. Other disadvantages [in The Module Pattern] include the inability to create automated unit tests for private members and additional complexity when bugs require hot fixes. It's simply not possible to patch privates. Instead, one must override all public methods which interact with the buggy privates.

   Isn't this more of a problem with encapsulation (with private members) per se rather than with The Module Pattern?

   One could also argue that this is not a disadvantage at all. Private methods are by definition implementation details and should not be unit tested directly. But I guess this is debatable, but still; I don't think this is a problem with the pattern, I think it's part of the nature of private members.

I'm gonna continue to enjoy the book now and I hope you don't mind me submitting besserwisser issues like this! ;)

[addyosmani]

I don't think the module pattern is similar to an IIFE; it uses an IIFE. And in an IIFE a function isn't necessarily returned, it's invoked. Don't you agree? :)

I agree @JonathanP. Master should now reflect this error in the way I originally described it :)

Isn't this more of a problem with encapsulation (with private members) per se rather than with The Module Pattern?

Coming back to this pattern a few years later, you're pretty right. This is more of a fundamental problem around encapsulation in JS than the module pattern itself. I wonder if there's a way we can better word this section.

The current book doesn't dive into any of the nuance around ES2015+ and more recent thinking about privacy in JS (WeakMaps, private/public class fields etc), although I think that might need to wait for a larger refresh of the book. Is there a good way you could see us rephrasing that paragraph? A PR would be welcome or we could iterate on wording here.