Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Healthy Hatred of OOP, or the principles of my message-driven framework

bythehilt.com

Post reply on HN
Print view View original

81–90 of 98 posts

Re: A Healthy Hatred of OOP, or the principles of my message-driven framework

#81

Post by jack9 »

jasode wrote: post #4

Your 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…

> No, good OOP has class/object with both private state and associated functions combined to provide a public interface for clients to use.

I don't believe there's evidence of this. Inteface scoping (e.g. "private/protected/public") is a relatively recent invention to protect against programmers who "don't know what they are doing". Adequate documentation is a superior tactic since that's a cursory best practice.

Re: A Healthy Hatred of OOP, or the principles of my message-driven framework

#82

Post by UK-AL »

kasey_junk wrote: post #63
UK-AL wrote: post #26

Earlier quoted context omitted.

Problem is developers take that as an excuse to make state public, which is even worse.

It doesn't matter whether you make the state public via a getter or via variables (modulo some compiler specific reasons to use accessors). If your design is allowing some external actor to work with multiple parts of the state of a behavior driven object (ie not a record) accessors are not going to help you, you've still exposed the state.

Completely agree.

But at least with getters/setters you can intercept calls before they modify state.

But you should design so you don't need this in the first place.

Re: A Healthy Hatred of OOP, or the principles of my message-driven framework

#83

Post by kazinator »

onnoonno wrote: post #78
kazinator wrote: post #33

Earlier quoted context omitted.

That's a big down side of a framework for asynchronous message passing (object-oriented or not). E.g. "Flow based programming". Message passing OOP doesn't necessarily imply that type of message passing. That is to say, the "send" call doesn't have to return until the target object has processed the message.

In a way, message passing using the usual way, methods, means TWO messages are passed: The parameters and the return value. I think that obscures the better parts of the OOP view quite a bit.

Also, method calls (that return) are really two calls, in a way: the call which passes the arguments along with a continuation, and then the call to the continuation which returns the value. :)

Re: A Healthy Hatred of OOP, or the principles of my message-driven framework

#84

Post by rdtsc »

Diederich wrote: post #48
zzzcpan wrote: post #32

Earlier quoted context omitted.

Don't take it seriously. Joe actually admitted, that they only called Erlang OOish because of the OO hype, but Erlang is not an OO language in any way, of course.

I would gently submit to you that Erlang is pretty close to the definition of 'Object Oriented' as given by the guy who created that phrase. The commonly held definition of OO has drifted far from that ideal over the years.

It is. But at this point it is rather tongue-in-cheek. I certainly wouldn't want Erlang to all of the sudden be called Object Oriented.

Re: A Healthy Hatred of OOP, or the principles of my message-driven framework

#85

Post by KirinDave »

jasode wrote: post #4

Your 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…

"Good" OOP and "bad" OOP. There's just no difference. And quite frankly, if the only difference between their "getX" and a symmetrical message passing pattern that retrieves a copy of an attribute is the implementation details then... what?

So much of "Good OO" seems to be prescribing people's mental models and not their actual practices. Seems somewhat odd to me, since most of the models are indistinguishable from one another in practice.

Re: A Healthy Hatred of OOP, or the principles of my message-driven framework

#86

Post by KirinDave »

kazinator wrote: post #30
jasode wrote: post #4

Your 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…

Moreover, getters and setters can be readily modeled with messages. That messages and (at least single dispatch) methods are identical was settled decades ago. (Has someone worked out a multiple dispatch OOP based on message passing?)

> That messages and (at least single dispatch) methods are identical was settled decades ago.

This has been modeled out from message passing and procedural code semi-formally, with the first discussion (that named the duality) being available here: https://cseweb.ucsd.edu/classes/wi08/cse221/papers/lauer78.p...

And it's fine for multiple dispatch as well, btw. Higher kinded types reward everyone equally here.

Re: A Healthy Hatred of OOP, or the principles of my message-driven framework

#87

Post by collyw »

atonparker wrote: post #21
jasode wrote: post #4

Your 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…

It seems to me like you and the author agree about what good OOP should be (encapsulated state, message passing), except they argue that "traditional" OOP is not useful, and you see Traditional OOP as Good OOP. In fact, "good" is not used a single time in the article so I don't see how they could be constructing a strawman against it. I'm guessing the author is using "traditional" in the sense of what is traditionall…

Seems that OOP is going the same way as Agile, and no one can come up with a consistent definition of what it is these days. Encapsulated state and message passing are not exclusive to the OOP paradigm are they?

Re: A Healthy Hatred of OOP, or the principles of my message-driven framework

#88

Post by Tloewald »

Retric wrote: post #72
Tloewald wrote: post #69

Earlier quoted context omitted.

Of course there's innate complexity, but pursuing encapsulation for its own sake adds complexity you don't need (just like using functional programming techniques for intrinsically non-functional use-cases adds complexity for no good reason). Again, "messages", "objects", etc. -- these are metaphors. They should be abandoned as soon as they stop being helpful.

Generally, if you don't want encapsulation then your not dealing with an independent object. You could write a game using 2 objects or 2,000, but building complex systems without partitioning becomes incredibly difficult. At the core Objects are a very basic abstraction. It can be as basic as Simulation Rendering, but it's hard to point to a complex system and say this really is best represented by a big ball of mud.…

Of course, but this guy is saying nothing shouldn't be, which is an even higher hurdle.

Re: A Healthy Hatred of OOP, or the principles of my message-driven framework

#89

Post by collyw »

jasode wrote: post #4

Your 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 am glad I work in a mixed metaphor language. Choose the best bits when appropriate instead of arguing what is proper OOP or not.

Re: A Healthy Hatred of OOP, or the principles of my message-driven framework

#90

Post by jasode »

collyw wrote: post #89
jasode wrote: post #4

Your 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 am glad I work in a mixed metaphor language. Choose the best bits when appropriate instead of arguing what is proper OOP or not.

> instead of arguing what is proper OOP or not.

Every programming paradigm and every programming language suffers the distinction of what is "proper" and "improper".

There's proper functional programming and improper functional programming. For example, it's possible to write bad code of passing GodUniverseState records to "functions" that the Haskell/Ocaml compiles without error. However, that's not "proper" functional programming. It's just messy global state masquerading as a functional program.

There's proper SQL usage and improper usage. For example, writing a stored procedure to loop through one table with a cursor, and then looking up a column value in another target table is "improper SQL". SQL has built in "joins" to do it correctly (and also performs faster as a bonus).

Even Python has a category of "not Pythonic".

Post reply on HN