There are some contradictions here. For example the author the following statement about encapsulation violations being permitted, but not followed as best prac

There are some contradictions here. For example the author the following statement about encapsulation violations being permitted, but not followed as best practice: "JavaScript does not enforce private state, but it’s easy to write well-encapsulated programs: simply avoid having one object directly manipulate another object’s properties. Forty years after Smalltalk was invented, this is a well-understood principle." However, the author doesn't seem to really understand this as he makes the case that access to private state and behavior of a "superclass" violates encapsulation: "In JavaScript (and other languages in the same family), classes and subclasses share access to the object’s private properties. It is not possible to change an implementation detail for Account without carefully checking every single subclass and the code depending on those subclasses to see if our internal, “private” change will break them." Well, yes they do allow access, but that doesn't mean you have to use it! This is considered bad practice when extending any class in other languages that I'm familiar with (C++, Ruby). Please take some of your own advice. I do agree that hierarchies do not fit the real world as well the contrived examples from my first OOP classes and they should be used with extreme caution. Let's not throw out the baby with the bath water, however.