Most of the problems he brings up are already addressed in major OOP languages.
1) Inheritance can be confusing and messy.
Yes, hence the advice: Prefer composition over inheritance. Instead of having B inherit from A, declare an interface I, and have both A and B implement I. If B wants to reuse A's functionality, it's free to do so through composition, and not through inheritance.
There are some edge cases where inheritance is vastly simpler than composition - mostly when the interface requires you to implement 20 different methods, and there's only 1 method that you really care about changing. Using inheritance here gets rid of a ton of boilerplate, but that's a conscious choice you're making. If you don't like this, just revert to using composition.
2) Encapsulations can leak if you write buggy code
Any program can break if you write buggy code. Not sure what the author's point here is. In order to encapsulate your class carefully, either accept immutable inputs, or make deep copies of them. If neither happens to work, warn users that class behavior is undefined if they misuse it. This is what every non-thread-safe class already does anyway: it warns users that if you use them in a concurrent manner, things may break.
More importantly, when dealing with internal state that's created by the class, make it private and ensure no one else can access it. This also serves to encapsulate the internal implementation and algorithm from external users.
3) Polymorphism is... not unique to OOP languages?
Yes, using interface-based polymorphism is a good idea, and covers most of what people need. How does this make the argument that we should never use OOP languages?
--------
The author brings up valid points about what to watch out for when coding in OOP. If you read other books like "Effective Java," they bring up the same points as well. But instead of acknowledging the benefits that come with OOP as well, and teaching people how to avoid these pitfalls and write code the right way, the author jumps to an extreme position that OOP languages should be abandoned entirely. Can we please avoid this type of wild overreaction, and pointless jumping from one shiny tool to the next, in a never-ending search for a silver bullet that will solve all of our problems. Because let's face facts: No such silver bullet exists.
The argument about encapsulation was the most confusing for me. I do not see where the problem is in the example he gives: either you want an object of class A to be used by multiple objects (of different classes possibly), and we have no problem, or you want every instance of A to be used by one and only one instance of some class B, and in that case like you said either you make a deep copy / create the object inside the constructor instead of passing it around. (if no state is needed)
I guess he does make a point about inheritance and how confusing it can be, but like you said OOP still has value outside of inheritance.
Soo..We said never look for something better than Java? Or OOP? What if FP gives us all the important things that OOP does and more? Why wouldn't we use it?
Personally I want to learn from and use a language that supports as many of the paradigms as possible, like Scala or Swift. Let me choose based on what I need. That being said I'd much rather work in pure FP then OOP because of the fact that most of the advantages of OOP can be achieved via FP and the inverse is not true.
1) Inheritance can be confusing and messy.
Yes, hence the advice: Prefer composition over inheritance. Instead of having B inherit from A, declare an interface I, and have both A and B implement I. If B wants to reuse A's functionality, it's free to do so through composition, and not through inheritance.
There are some edge cases where inheritance is vastly simpler than composition - mostly when the interface requires you to implement 20 different methods, and there's only 1 method that you really care about changing. Using inheritance here gets rid of a ton of boilerplate, but that's a conscious choice you're making. If you don't like this, just revert to using composition.
2) Encapsulations can leak if you write buggy code
Any program can break if you write buggy code. Not sure what the author's point here is. In order to encapsulate your class carefully, either accept immutable inputs, or make deep copies of them. If neither happens to work, warn users that class behavior is undefined if they misuse it. This is what every non-thread-safe class already does anyway: it warns users that if you use them in a concurrent manner, things may break.
More importantly, when dealing with internal state that's created by the class, make it private and ensure no one else can access it. This also serves to encapsulate the internal implementation and algorithm from external users.
3) Polymorphism is... not unique to OOP languages?
Yes, using interface-based polymorphism is a good idea, and covers most of what people need. How does this make the argument that we should never use OOP languages?
--------
The author brings up valid points about what to watch out for when coding in OOP. If you read other books like "Effective Java," they bring up the same points as well. But instead of acknowledging the benefits that come with OOP as well, and teaching people how to avoid these pitfalls and write code the right way, the author jumps to an extreme position that OOP languages should be abandoned entirely. Can we please avoid this type of wild overreaction, and pointless jumping from one shiny tool to the next, in a never-ending search for a silver bullet that will solve all of our problems. Because let's face facts: No such silver bullet exists.