1. Agreed... this is irrelevant to OOP and in fact, it's possible to achieve data hiding with pretty much any language, including assembly, which aren't a first class OOP language.
2. Not sure as well... I think he's talking about cases like in Java where you cannot have a function that isn't associated with an object, even if that object has no data that it retains. If so, I can understand... it's kinda stupid since there's no information to communicate with. It would really depend on use case but in most cases, even in Java, I find myself considering these cases bad application design rather than a folly of OOP.
3. OOP doesn't care about where the data it's associated with is created.
4. Uh... erm... I'd better not answer this one...
They added traits, mixins, and interfaces to try to fix the initial problem that object-oriented programming had attempted to solve. |
"traits, mixins, and interfaces" are not a fix for OOP nor does OOP try to solve these things. traits and mixins are viable for non-OOP-based languages. I don't really see a problem with interfaces, they're a form of data communication.
<codesnip> ...would have sufficed. No magic here. |
I don't really get what he's talking about... almost any OOP based language can do along the lines of his example. I don't know what magic he's talking about.
Stuff like hierarchical classes, inheritance, and garbage collection. Why? |
I oddly agree. I dislike all of the above and avoid them like a plague... has made code and my life magnitudes easier.
Hierarchies are one of the reasons why I spend too much time planning when writing OO code rather than actually writing code. |
I feel like that's more of a lack of experience rather than the fault of OOP. You also do not have to use a class hierarchy at all (including in Java).
Inheritance is just a horrific idea when you really think about it. Exhibit A: A free foundation called 'Uber Codes' writes an audio framework. Another large group writes an interface to that framework to make it available in a different programming language. Your company decides to use that interface. About a year later, out of the blue, 'Uber Codes' sells their audio framework to a large corporation, and the framework is made proprietary. Then, over the next few months, that corporation terminates support for that product. Now you're screwed. You either have to wait for the group that created the interface to write a new back end or switch your entire code base to a new audio framework. For those of you thinking, 'man, that seems like a pretty specific example...', that's because it's actually happened before with a product called OpenAL. |
I don't see how that helps his point about inheritance being bad *at all*. I don't recall this ever happening with OpenAL anyways...
I don't like Garbage Collection so I can mildy agree with his comments on GC by skimming over them.
EDIT: Although yeah, GC has nothing to do with OOP and is just as usable in a non-OOP language...