How's your standard units solution going to work when the users consider their input units to be part of the data? Are you going to store their units alongside the converted units and convert them back whenever you want to display? If so, you've just replaced Matt's example problem with an identical problem. This is a clue that you have insufficient abstraction: a small change of requirements can force a lot of code to be written across your application. And don't assume you can dictate units to your users, there are plenty of situations in which the users and their units are vastly more important than the programmer's time and ease.
That's kind of my point. The problem isn't primitives. The problem exists no matter what you do: you still need to do conversions based on the user's inputs and the program's output.
>How's your standard units solution going to work when the users consider their input units to be part of the data?
In which case, the user will be inputting the unit and the amount, and telling me what units they want to use as an output. Internally, once this is passed from the interface, you convert the unit to your standardized unit. Similarly, when printing it out, you convert it back to the user's selected unit. Again, this is simply calling the convert function when the data is initialized, and calling it again when it's printed.
OO does not magically solve this problem. If you're storing it in the user's selected type, then every time any function accesses the data, they're either going to have to code around the different types, or call convert() to get it into the type they want. So from a developer's perspective, this is the difference from 2 guaranteed conversions(at input and output time), versus conversions whenever the data is accessed, and at output time.
>And don't assume you can dictate units to your users, there are plenty of situations in which the users and their units are vastly more important than the programmer's time and ease.
Actually, as a developer, you DO dictate units to your users if you're doing anything more than just storing and regurgitating the data. If the user selects a salbartifast unit, then you absolutely need to know how it related to grams, BU, or whatever else you're using in order to use it in any of your calculations.
But I've never seen a system like that for something like carb counting - it's always normalized, and everything is displayed in a single unit at a time, maybe changeable by user preference. Maybe the problem is that so far nobody has built such a system. Maybe it's that doing so means more complex SQL queries and larger indexes, because you need to consider two fields instead of one when summing / averaging / etc. Maybe it's because users don't want it.
The argument for ints in this case is also an argument that you should only show a single unit at a time. So long as that's true, the encapsulation argument carries a lot less weight - at that point, I'm not sure which I'd choose. The benefits are a lot less real, though.
Astronomy is the one field where it makes perfect sense to store the units, because basically nobody agrees on what the standard should be. My professor in college joked that if you had 5 astronomers in the room, you'd get 10 different sets of "standard" units.
By leaving it as an int, I (and the rest of the team) have to know that the value is not suitable for display. Moving to a value object is not the only way to solve this issue; I could have introduced a `CarbsView` that handled the conversions and it would have solved the issue as well. A lot of this kind of stuff just comes down to personal (and team) preferences for designing your app.
Internally, you want a standard set of units. It doesn't matter what they are: grams, bread units, etc. It only matters that they're standard across the application. That reduces the complexity of the actual functionality, which is presumably totaling up the information and comparing it to whatever limits the user inputs. You don't want to have to switch all your internal logic based on user input type, you want to convert user inputs to a standard field type and work from there. Honestly, different calculations based on multiple unit types is as big a code smell as converting the input data.
So realistically, it's the same effort no matter what input type the user has: Either you're converting it at the base, converting it before you do your calculations, or writing several specific cases for each input type. It's the same number of test cases, too.