4 ms·

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 sev

by 0xCAP 3y ago

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.

tester756 3y ago
>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 like `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.
- 0xCAP 3y ago
  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.
  - tcfhgj 3y ago
    > 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
  - Mawr 3y ago
    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.
    - runald 3y ago
      > 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.
- Seb-C 3y ago
  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.
  - esafak 3y ago
    nim has distinct types, kotlin has inline classes, scala has type aliases. It is a good feature.
biorach 3y ago
> 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

by 0xCAP 3y ago

tester756 3y ago

>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 like `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.

0xCAP 3y ago
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.
- tcfhgj 3y ago
  > 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
- Mawr 3y ago
  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.
  - runald 3y ago
    > 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.
Seb-C 3y ago
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.
- esafak 3y ago
  nim has distinct types, kotlin has inline classes, scala has type aliases. It is a good feature.

biorach 3y ago

> 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