Hacker News Reader

Comment by 0xCAP | Hacker News Reader

I've had the pleasure to work with an immensely talented developer who would spam unnecessary patterns all over the codebase, to the point where it required several coffees just to go through a single branch of domain logic. Even the IDs of his aggregates were classes.

At the same time, though, I feel very disheartening that at my current company devs ignore what even "aggregate" means, and don't have any kind of clue about patterns and higher concepts in general. I really miss smart and educated people in IT.

View on HN

>Even the IDs of his aggregates were classes.

People were arguing for such a thing because e.g

if you have 2 guids then you can write code which handles two completely unrelated guids

`student.Id == car.Id`

meanwhile if you have types like StudentId and CarId then you'd have compilation error

While I'm not a fan of this, then the concept is sound.

I have done that in Go and Typescript ("branded types"), it's actually very useful to discriminate ids. It prevents stupid mistakes that are actually hard to spot. Making it a whole class is maybe going too far however, as the costs may outweight the benefits.

nim has distinct types, kotlin has inline classes, scala has type aliases. It is a good feature.

Yes, this is a philosophical issue that lies within our attempts to model reality in our systems. What defines identity? A dog named Brian is not the same as a man named Brian.

For value objects, surely Leibniz's philosophy applies: if a theory describes two situations as being distinct, and yet also implies that there is no conceivable way, empirically, to tell them apart, then that theory contains some superfluous and arbitrary elements that ought to be removed.

For entities, it's much more complex.

I still feel some kind of way when seeing classes (with methods!) being used for IDs, though.

I've no clue what you just said :)

Modeling the business domain with types that match it is table stakes. Otherwise you end up with a "stringly-typed" codebase in which everything is just a primitive type.

This and the issues the author of the article is facing comes from the wrong mindset. Your job is not to create the purest, most perfect codebase, but to deliver value to your users. Code is a means to an end.

> I've no clue what you just said :)

This. Before you wax all philosophical, try to understand first what you are arguing for and against. Make sure to read what you wrote at least two times, and that it actually makes any sense.

> still feel some kind of way when seeing classes (with methods!) being used for IDs, though.

Depends on the language. In many languages strings are classes in general, so it makes sense that a new type for a strong is is one as well

> an immensely talented developer who would spam unnecessary patterns all over the codebase

He may have been talented but unnecessary patterns are the hallmarks of a bad programmer

Reply on news.ycombinator.com