A Healthy Hatred of OOP, or the principles of my message-driven framework
1–10 of 98 posts
Re: A Healthy Hatred of OOP, or the principles of my message-driven framework
#2I think that we suffer from a paucity of precise language around OOP. Everything is OOP, everything is what Kay created, etc.
But that's clearly not the case, and so people have these radically divergent systems of programming within the framework of "object orientation".
My read of this article and it is very message-passing OO to me. Its broadcast mechanism is interesting, for sure. But it reads a lot like Erlang's supervision tree without all that troublesome thinking about a network.
But it's approach is still very "OO".
Re: A Healthy Hatred of OOP, or the principles of my message-driven framework
#3A traditional OOP approach would have much of the functionality taken out of the player objects, using them simply to hold state.
I don't agree with that characterization. The author certainly has a point that, in some languages in particular, like java, there tend to be massive over-decomposition of problems into reams of factories, controllers, controller factories and controller factory manager factories, but that isn't OOP, that's due to cultural and syntactic issues with those languages. (I know, I know, No True Scotsman.)
In the Rails world, which is a non-trivial component of the broader OOP software world, there is a saying: "Fat Model, Skinny Controller" which is much more in the spirit of what the author is advocating, despite remaining OOP.
Again, this isn't to deny the authors general point, but I don't believe it is bound to OOP, so much as it is to a certain style of OOP coding that arose from early (java in particular) over-engineering and excessive decomposition.
Re: A Healthy Hatred of OOP, or the principles of my message-driven framework
#4Your essay is arguing against a strawman of what "good" OOP is supposed to be. Your examples...
>Objects just aren't supposed to be reaching into each other with 'getters' and 'setters' and messing with information.
The getX() and setX() is an anti-pattern of good OOP.
>Instead of using objects for compartmentalizing functionality, they were just used as a holding pen for loosely related functions.
No, good OOP has class/object with both private state and associated functions combined to provide a public interface for clients to use.
(Although Java & C# (unlike C++) may have muddled this aspect because their language specification does not allow "free" functions to live in a plain namespace. Therefore, programmers are forced to use the "class{}" keyword with static functions as a workaround. Maybe that's where your "holding pen" characterization came from?)
>A traditional OOP approach uses shadowy architecture to remove the responsibility of an object,
No, good OOP tries to push responsibility into classes/objects so they can act as independent agents with minimal coupling to the outer context they sit in.
I'm guessing your comments are based on seeing a lot of poor practices masquerading as OOP which affects what you think OOP actually is. Unfortunately, it's like trying to argue against Javascript because of overuse of "eval()" or arguing the flaws of Haskell because variable names are often 1 character long.
There are definitely problems with OOP but they are not the bullet points you mentioned.
Re: A Healthy Hatred of OOP, or the principles of my message-driven framework
#5Your essay is arguing against a strawman of what "good" OOP is supposed to be. Your examples... >Objects just aren't supposed to be reaching into each other with 'getters' and 'setters' and messing with information. The getX() and setX() is an anti-pattern of good OOP. >Instead of using objects for compartmentalizing functionality, they were just used as a holding pen for loosely related functions. No, good OOP has c…
I think your comment highlights my biggest problem with OOP: no one agrees on what it is or how to organize it. The amount of mental energy I used to spend on exactly how things should be separated into objects and how those objects interacted was astronomical.
Re: A Healthy Hatred of OOP, or the principles of my message-driven framework
#6The downside of message passing is debugging. No call stack so you can't trace things back to their source.
Re: A Healthy Hatred of OOP, or the principles of my message-driven framework
#7The less actual code I see in articles like this, and the more abstraction I read about, the less I take the concept seriously.
In fact, all of this seems like bullshit to me. The actual code inside of the repo is, well, object-oriented. How I interpret this is that the author seems to have no idea what they're even talking about, and that they write more about code than they write code itself.
Show me what you mean, don't just talk about it.
Re: A Healthy Hatred of OOP, or the principles of my message-driven framework
#8I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind
-- Alan Kay, OOPSLA '97
Re: A Healthy Hatred of OOP, or the principles of my message-driven framework
#9Your essay is arguing against a strawman of what "good" OOP is supposed to be. Your examples... >Objects just aren't supposed to be reaching into each other with 'getters' and 'setters' and messing with information. The getX() and setX() is an anti-pattern of good OOP. >Instead of using objects for compartmentalizing functionality, they were just used as a holding pen for loosely related functions. No, good OOP has c…
>I'm guessing your comments are based on seeing a lot of poor practices masquerading as OOP which affects what you think OOP actually is
I personally feel that the current OOP model eventually devolves into the bullet points you listed given enough complexity.
One reason why I think this occurs is that there is no concept of a 'message' in OOP, only methods or functions of a class. There's explicit coupling even when calling a method with no arguments because you know the method is valid for that object.
Contrast this with the example of the 'listener' in the room. A speaker broadcasts his message but the independent agents ultimately decide what to do with that message.
The OOP approach calls "object->listen" on each listener. My approach simply broadcasts the message and lets the objects determine how to handle it themselves.
Re: A Healthy Hatred of OOP, or the principles of my message-driven framework
#10The less actual code I see in articles like this, and the more abstraction I read about, the less I take the concept seriously. In fact, all of this seems like bullshit to me. The actual code inside of the repo is, well, object-oriented. How I interpret this is that the author seems to have no idea what they're even talking about, and that they write more about code than they write code itself. Show me what you mean,…
I should have a tutorial out very soon. The documentation is not yet complete but does have a few examples.
Also, of course it's object-oriented. The article is titled a "healthy" hatred for a reason.