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

31–40 of 58 posts

Re: When objects are not enough (2021)

#31

Post by eyelidlessness »

odipar wrote: post #29
eyelidlessness wrote: post #20

Earlier quoted context omitted.

Object identity effectively implies mutability. Without that implication, two objects of the same structured value being non-equal doesn’t mean anything (and would probably be better classified as a mistake). Another way to look at it is that property setters (or whatever mechanism is used to directly mutate an object’s sub-data) is not meaningfully different from a method doing the same. You could even call it synta…

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-value-different-version objects not otherwise interchangeable unless/until some value change does occur?

Re: When objects are not enough (2021)

#33

Post by hcarvalhoalves »

artemonster wrote: post #3

I never liked „OOPs world“ obsession with a receiver. Why the hell receiver of a message gets to dispatch the implementation at very late moment? Why not context? And when there are many receivers? I.e. a composite object of an int and a float receive message „add“ - who decides which implementation to use and why the heck any of them may even know how to add self to another? There were many attempts to solve this an…

If you want a "receiverless message", you want a queue surely?

Re: When objects are not enough (2021)

#34

Post by dullcrisp »

bob1029 wrote: post #15

The objects are just one tool. You usually need a few to do the job well. The biggest thing I've seen blow up actual OOP projects has been a lack of respect for circular dependencies in the underlying domain. If you have one of those problems where it is ambiguous which type "owns" another type, then the moment you start writing methods in these types you are treading into the dark forest. Often times it is unclear t…

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

Re: When objects are not enough (2021)

#35

Post by codr7 »

artemonster wrote: post #3

I never liked „OOPs world“ obsession with a receiver. Why the hell receiver of a message gets to dispatch the implementation at very late moment? Why not context? And when there are many receivers? I.e. a composite object of an int and a float receive message „add“ - who decides which implementation to use and why the heck any of them may even know how to add self to another? There were many attempts to solve this an…

Why not generic methods like in Common Lisp?

Re: When objects are not enough (2021)

#36

Post by Swizec »

dullcrisp wrote: post #34
bob1029 wrote: post #15

The objects are just one tool. You usually need a few to do the job well. The biggest thing I've seen blow up actual OOP projects has been a lack of respect for circular dependencies in the underlying domain. If you have one of those problems where it is ambiguous which type "owns" another type, then the moment you start writing methods in these types you are treading into the dark forest. Often times it is unclear t…

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

> Why would a type ever own another type?

FHIR, an international standard for medical data, is a great example here. The circular types get so gnarly that I've personally managed to infinite-recursion the TypeScript compiler. We even managed to get 45min builds followed by a timeout by sneezing wrong.

https://www.hl7.org/fhir/overview.html

The tldr is that you can have things that belong to things that belong to things that end up belonging to the original thing after a very very long inscrutable chain of pointers. Essentially a graph.

Re: When objects are not enough (2021)

#37

Post by bob1029 »

dullcrisp wrote: post #34
bob1029 wrote: post #15

The objects are just one tool. You usually need a few to do the job well. The biggest thing I've seen blow up actual OOP projects has been a lack of respect for circular dependencies in the underlying domain. If you have one of those problems where it is ambiguous which type "owns" another type, then the moment you start writing methods in these types you are treading into the dark forest. Often times it is unclear t…

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 unclear which type should be king.

The relational approach is to use a join table. Model the actual relationship itself and its relevant attributes (role on the account, beneficiary %, etc). This also handles any arbitrary graph of accounts and customers, assuming you are using a modern database engine that supports with recursive & cycle keywords.

ORMs will blow up on this kind of thing without special handling.

Re: When objects are not enough (2021)

#38

Post by trgn »

asgeir wrote: post #6
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.

It's not a requirement, but an immutable object has fewer uses than a mutable one. Functions/methods/actions/operations are just different names for the operations which mutate the state of the object. So, I would argue that they are a necessary attribute of mutable objects.

So weird this is getting down voted. Immutable objects would just be structs with sugar. It's mutability that gives you the power to keep a reference to an object, but have it keep up with the operational lifecucle of your app/process/..

Re: When objects are not enough (2021)

#39

Post by stonethrowaway »

I want to agree with this but it’s a surface level concern. I’m not trying to belittle the author’s point but I do want to emphasize something that isn’t talked about enough.

Reification has two meanings in software development. Author uses one, the more familiar one - it’s discussed in many books on DDD. The other is a bit more vague and unapproachable. It’s the one I want to bring to peoples attention. It can be summed up as: “Accounts, transactions and balances are not enough.”

Jim Weirich hints at this perfectly in his approach to solving the Coffee Maker [0]. I’ll quote the punch line for everyone:

> Some people may be uncomfortable with the divergence of the Analysis and the Design models. Perhaps they expect that the design model will just be a refinement of the analysis. Remember that analysis is an attempt to understand the problem domain. Although we use OO tools to represent our understanding, that understanding has only an indirect influence on the structure of the software solution (in that the software must actually provide a solution). In fact, as we refine our software design, we will find that it moves even farther away from the analysis model. Solutions oriented classes, which do not appear in analysis, will be added to the design. Classes that came from the analysis model may mutate or even disappear entirely.

This is the form of reification that I believe is more closely associated with how the term is used in classical OOD (f.e. Object Oriented Software Engineering: A Use Case Driven Approach), but I suppose people’s experiences may disagree. This is a kind of “right layer of abstraction” that has to be pontificated and not just put down as an object because it’s a process or a “thing” from the outwardly-behavioural view of the situation.

As I mentioned, it’s not talked about enough. Jim is right to call it out: it’s uncomfortable because it’s having to dig deep into the system ontology.

[0] http://www.cs.unibo.it/cianca/wwwpages/ids/esempi/coffee.pdf

Re: When objects are not enough (2021)

#40

Post by binary132 »

dullcrisp wrote: post #34
bob1029 wrote: post #15

The objects are just one tool. You usually need a few to do the job well. The biggest thing I've seen blow up actual OOP projects has been a lack of respect for circular dependencies in the underlying domain. If you have one of those problems where it is ambiguous which type "owns" another type, then the moment you start writing methods in these types you are treading into the dark forest. Often times it is unclear t…

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

Maybe like how having a handle back to something can be a parent-child relationship or can imply that the child owns the parent, especially if the lifetime is extended by the ownership (e.g. shared pointer).
Post reply on HN