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

When objects are not enough (2021)

tonysm.com

Post reply on HN
Print view View original

41–50 of 58 posts

Re: When objects are not enough (2021)

#41

Post by AtlasBarfed »

mattgreenrocks wrote: post #19

I want to re-read this and think about it more. But one thing stuck out: I never liked most of the distillation of actions as clean architecture would advocate for, be they lambdas in class form (DepositAction) or interactors. I feel strongly that they are the right thing in describing business logic, however. What did click for me is the conceit of a service, which the JVM world embraces. Services are plain old obje…

"Services" in the JVM, usually in the sense of Spring or some other service management framework, is just procedural code with a thing object instantiation layer which allows late binding invocations across services, which in complicated code turns out to be enormously useful:

- enable/disable/manage caching layers to procedure... uh... method calls

- play tricks with remote invocations that look like local ones

- enable advanced testing frameworks with mocked parameters and data connections

- enable/disable logging at runtime, and target specific services

- "aspects" to target various patterns of invocation and inject interceptors/decorators/etc to the procedure... uh... method call.

JVM service management OOP is a very different thing than domain/data object modeling OOP. JVM service management OOP is a slam dunk in terms of delivered value. In the referenced Alan Kay bullet points, it is mostly extreme late binding, and kind-of message passing that delivers tremendous value.

Data modeling OOP and GUI framework OOP is the old dog is-a animal, but is-a pet and all that headache. Because Java's behavioral compositional model is basically single inheritance (yeah, there's interfaces if you want to copy-paste or write your own delegates), it is fundamentally limited. That is the OOP that has squarely and properly been questioned over the last 10 years.

Re: When objects are not enough (2021)

#42

Post by fiddlerwoaroof »

ChrisMarshallNY wrote: post #5

> An object has state and operations combined. My own definition has always been that an object has state and identity . I have never considered functions/methods to be a requirement for something to be an object.

Yeah, I think the best object systems (CLOS and friends) intentionally decouple objects from functionality.

Re: When objects are not enough (2021)

#43

Post by bccdee »

goatlover wrote: post #27
menotyou wrote: post #26

Yet another article about problems you'd never have if you wouldn't use object oriented paradigm.

But then you'd have other problems that come with using another paradigm, since there's no silver bullet, and no paradigm that handles all problems better than other paradigms. Probably popular languages tend to be multi-paradigm.

That's not really true. Structured programming completely supplanted the paradigm that predated it. I think it's pretty close to a consensus now that null values are a mistake. Same with manual memory management.

Re: When objects are not enough (2021)

#45

Post by odipar »

eyelidlessness wrote: post #31
odipar wrote: post #29

Earlier quoted context omitted.

My take is that identity doesn't imply mutability, if you version objects. It could well be that your are looking at an old version of an object, using its unique identity combined with its version (number). Objects refer to other objects using their (immutable) identity. In turn, resolving identities to objects requires (version) scope which can be in the past or present.

> My take is that identity doesn't imply mutability, if you version objects. It could well be that your are looking at an old version of an object, using its unique identity combined with its version (number). Are you storing the version as part of the object? If so, they’re no longer equal values regardless of identity. If not, what purpose is there in versioning the same value? Even if there is a purpose, are same-…

Identity doesn't imply 'value' equality, that's the whole point of mutability! Conversely, two objects can have the same 'value' while having different identities. Values and objects are different beasts.

Re: When objects are not enough (2021)

#46

Post by meheleventyone »

artemonster wrote: post #23
meheleventyone wrote: post #7

Earlier quoted context omitted.

Maybe I'm misunderstanding but the whole point of any messaging system is that the sender "doesn't know how to process the message" and it's up to the receivers to process it and coordinate amongst themselves. Otherwise you could just do the processing where the message was sent. For non-OOP examples you have most service architectures. So from that perspective an int-float object would be built by composition and th…

then why the receiver would know too? There are more parties in this orgy: message receiver, message sender (method caller), environment (static: like imports), context (dynamic: like stack). Why the heck of all of those the receiver decides?

I'd take all of those as receivers if they are reacting to a message being sent.

To give another example in a game engine I recently worked on we sent messages between game entities and the sending entity could target itself directly and indirectly with no problems and a common pattern to keep components of the entity decoupled was to do just that.

In some OOP languages the environment and everything else are all objects. I think Smalltalk itself works that way. Which reflects this way of thinking.

Re: When objects are not enough (2021)

#47

Post by meheleventyone »

c-linkage wrote: post #21
meheleventyone wrote: post #7

Earlier quoted context omitted.

Maybe I'm misunderstanding but the whole point of any messaging system is that the sender "doesn't know how to process the message" and it's up to the receivers to process it and coordinate amongst themselves. Otherwise you could just do the processing where the message was sent. For non-OOP examples you have most service architectures. So from that perspective an int-float object would be built by composition and th…

In OOP as I understood it, messages are first-class entities at the same level as "objects". This is strikingly different from modern OOP languages where a message is conflated with "function calls". This is pointed out in the article: "[I]n Smalltalk, messages 'were not real messages but disguised synchronous function calls', and this mistake was also repeated in other languages[...]". If a message is a first class…

Yeah I was intentionally not talking about OOP but about messaging because I think the concept quite obviously transcends the programming paradigm and I often use it as you suggest.

That said one way of processing messages is to relate the message name to a method name at runtime and that is quite successful which is where I think the stronger version of that linking comes from in other languages that have static binding. It's still the same messaging concept but the routing is resolved at compile time which has tradeoffs.

Re: When objects are not enough (2021)

#48

Post by facturi »

bob1029 wrote: post #37
dullcrisp wrote: post #34

Earlier quoted context omitted.

Why would a type ever own another type? What would that even mean? Like an inner class? Or are you taking about ORMs?

Think about a collection of one related type on another, such as Customer -> Accounts + Account -> Customers. In banking, it is possible for one customer to have many accounts, and for each account to have many customers. OOP will let you express this kind of problem from a data modeling perspective (List on each type), but from a serialization and dependency perspective you have to pick a "winner". In banking, it is…

This is related: Why relations are better than objects https://www.cell-lang.net/relations.html

Re: When objects are not enough (2021)

#49

Post by ryandv »

> Smalltalk was one of the first Object-Oriented Programming Languages out there. It's where ideas like inheritance and message-passing came from (or at least where they got popular, from what I understand);

It may be worth pointing out that while Smalltalk is arguably one of the key languages that popularized such ideas and other OOP concepts, these were first introduced by Simula 67.

Post reply on HN