3 ms·

The way is see ValueObjects is as the most convenient tool when working with a very well-defined space. For example, integers on the number line. There’s no unc

The way is see ValueObjects is as the most convenient tool when working with a very well-defined space. For example, integers on the number line. There’s no uncertainty— 2 is 2 is 2. Same goes for a 2D coordinate within a 2D space, or 3D coordinate… etc. The “date space” is quite well-defined these days, as long as you’re working with a Gregorian calendar and typical timezones. It’s at the limit of “coordinate within a space” but as programmers and with training we can handle it. Once you start getting away from simple, well-defined spaces, things start to get complex. What is a “phone number space”? Or a “given name & surname” space? They exist, but they are insurmountably complex — both for us and for code — and are ever-changing as the world changes. So we bring order by converting these problem to a well-defined space that we know how to work with: strings. Or rather, strings that conform to certain patterns (numbers for a phone number). This is a grey-area. ValueObjects may be useful, or may just complicate matters. But not all problems can be mapped to strings. Customers have N sales orders. Sales orders have X lines. Lines refer to inventory items with Y modifiers. You could probably define the “space of all customers, sales orders, inventory items & modifiers” but it would have so many dimensions, and be mostly enormous regions of non-sense. This is where ValueObjects have no place.

duped 4y ago
> not all problems can be mapped to strings I think that statement is at odds with the Turing-Church hypothesis, but I understand that is pedantic
nextaccountic 4y ago
> What is a “phone number space”? Do you need to call the phone number? Then you probably need to type it. If two phone numbers when typed result in the same number, they are the same. So you probably want to normalize your numbers: remove ( or - or spaces or anything that isn't actually meant to be typed, then you can compare two phone numbers. Of course it doesn't end there. There's another, looser equivalence between phone numbers that are much more useful: if we call both numbers, will they call the same phone? Things like presence vs absence of country codes, area codes and other things could be part of your normalization. But then, you would need to keep the context in which each phone number was collected. For example, if someone in a given city tells they have a phone number, and someone else in another far away city informs the same phone number, they probably refer to different phones (because the area code is likely different) What's better, of course, is to ask for country code and area code in the same form. If all your phone numbers are "fully qualified", then you can just compare them for equality. But this is not always possible So this kind of thing is fuzzy and has edge cases, but getting it right is essential if you want to search for two people with the same phone number (for example). Since there are edge cases, it's important that phone numbers are stored exactly as they were input, and then normalize as a separate column or something.
ajuc 4y ago
> The way is see ValueObjects is as the most convenient tool when working with a very well-defined space. My main problem with OOP in general is that people try to write programs in ill-defined spaces without defining them first. OOP promises it will be fine: just hide everything behind black boxes and nobody needs to know what actually happens on zeroes and ones level. But it's a lie - somebody needs to make a conscious decision on what happens on data level. It needs to be well defined or you'll get a huge object-oriented ball of spaghetti code. Which if you ask me is even worse than procedural spaghetti code (cause it's harder to refactor). So once you define your data space well - value objects are usually a good idea, even for complex types with variable-length containers inside. The main exception is when you need in-place modification for performance reasons, but it's rare in business code.

duped 4y ago

> not all problems can be mapped to strings I think that statement is at odds with the Turing-Church hypothesis, but I understand that is pedantic

nextaccountic 4y ago

> What is a “phone number space”? Do you need to call the phone number? Then you probably need to type it. If two phone numbers when typed result in the same number, they are the same. So you probably want to normalize your numbers: remove ( or - or spaces or anything that isn't actually meant to be typed, then you can compare two phone numbers. Of course it doesn't end there. There's another, looser equivalence between phone numbers that are much more useful: if we call both numbers, will they call the same phone? Things like presence vs absence of country codes, area codes and other things could be part of your normalization. But then, you would need to keep the context in which each phone number was collected. For example, if someone in a given city tells they have a phone number, and someone else in another far away city informs the same phone number, they probably refer to different phones (because the area code is likely different) What's better, of course, is to ask for country code and area code in the same form. If all your phone numbers are "fully qualified", then you can just compare them for equality. But this is not always possible So this kind of thing is fuzzy and has edge cases, but getting it right is essential if you want to search for two people with the same phone number (for example). Since there are edge cases, it's important that phone numbers are stored exactly as they were input, and then normalize as a separate column or something.

ajuc 4y ago

> The way is see ValueObjects is as the most convenient tool when working with a very well-defined space. My main problem with OOP in general is that people try to write programs in ill-defined spaces without defining them first. OOP promises it will be fine: just hide everything behind black boxes and nobody needs to know what actually happens on zeroes and ones level. But it's a lie - somebody needs to make a conscious decision on what happens on data level. It needs to be well defined or you'll get a huge object-oriented ball of spaghetti code. Which if you ask me is even worse than procedural spaghetti code (cause it's harder to refactor). So once you define your data space well - value objects are usually a good idea, even for complex types with variable-length containers inside. The main exception is when you need in-place modification for performance reasons, but it's rare in business code.