3 ms·

I don't see the problem with primitives here. Realistically, the alternatives are either to store a standardized float, or a struct that contains a float and a

by cube13 14y ago

I don't see the problem with primitives here. Realistically, the alternatives are either to store a standardized float, or a struct that contains a float and a type value. Floats have issues themselves with accuracy that need to be accounted for, so it's pretty easy to see why they tend to be avoided. 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.

fusiongyro 14y ago
It's the same effort to the machine, not the developer. If the objects manage their own units, you can just use them naively and let them handle their conversions during arithmetic if they need it. You don't need to write the code for conversion explicitly anywhere outside the class. This is a material advantage of object-oriented programming, consolidating the knowledge about one aspect of your program to the right place to deal with it and keeping it out of the rest of the codebase. 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.
- cube13 14y ago
  >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. 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.
  - fusiongyro 14y ago
    Actually, Matt and I are are both independently saying that OO does magically solve this, because it has. It doesn't look like either of us have made it clear enough for you that this is the case, but it isn't a matter of debate: the codebase I work on at work has greatly benefited from it, and this fact isn't really vulnerable to your conception of why it must be the same amount of work. You're not seeing that it isn't. This is a communication problem.
  - 14y ago
swanson 14y ago
I agree completely about the standard units - I was able to get that right in the production code fortunately. The biggest gain I can see from moving away from the primitive is from a developer's point of view. 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.
- jdlshore 14y ago
  You might be interested in Ward Cunningham's "Whole Value" pattern [1] which is part of his awesome CHECKS pattern language [2]: [1] http://c2.com/ppr/checks.html#1 http://c2.com/ppr/checks.html#1 [2] http://c2.com/ppr/checks.html http://c2.com/ppr/checks.html

by cube13 14y ago

fusiongyro 14y ago

It's the same effort to the machine, not the developer. If the objects manage their own units, you can just use them naively and let them handle their conversions during arithmetic if they need it. You don't need to write the code for conversion explicitly anywhere outside the class. This is a material advantage of object-oriented programming, consolidating the knowledge about one aspect of your program to the right place to deal with it and keeping it out of the rest of the codebase. 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.

cube13 14y ago
>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. 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.
- fusiongyro 14y ago
  Actually, Matt and I are are both independently saying that OO does magically solve this, because it has. It doesn't look like either of us have made it clear enough for you that this is the case, but it isn't a matter of debate: the codebase I work on at work has greatly benefited from it, and this fact isn't really vulnerable to your conception of why it must be the same amount of work. You're not seeing that it isn't. This is a communication problem.
- 14y ago

swanson 14y ago

I agree completely about the standard units - I was able to get that right in the production code fortunately. The biggest gain I can see from moving away from the primitive is from a developer's point of view. 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.

jdlshore 14y ago
You might be interested in Ward Cunningham's "Whole Value" pattern [1] which is part of his awesome CHECKS pattern language [2]: [1] http://c2.com/ppr/checks.html#1 http://c2.com/ppr/checks.html#1 [2] http://c2.com/ppr/checks.html http://c2.com/ppr/checks.html