You could provide even more clarity by using meaningful types like Money or TaxPercentage instead of Double.
This would allow you to ensure only valid values are passed and would help avoid problematic floating point arithmetic :)
This would allow you to ensure only valid values are passed and would help avoid problematic floating point arithmetic :)
I recently came across a codebase that implement type classes for almost all types of things it handles and found that to be overkill. Almost always, name and age can be represented by a string and an integer respectively; separate Name and Age classes just reduce the readability in your code.
Reasonable support here mostly means that you can implement operator overloads, so that you can define e.g. a Money type that can be added but not multiplied.
Money handling may not actually be such a good example for this, because you should really have proper unit testing there anyway. I did work on a codebase that had types for SI units, and it was quite a nice experience.
I would now have to look up the implementation of Money and TaxPercentage to be sure of what it does, whereas if you move the type names into the variable names like in the following examples: 'double total_money' and 'double tax_percentage' I would immediately understand what's going on.
I do see how a TaxPercentage type allows you to create a type that restricts itself to percentages. I feel that it is serves readability better to leave this checking to the function using the value itself rather than having the type do it.
How can you find all the uses of money throughout your codebase if they're just doubles? They'll be mixed up with all other uses of doubles.
What happens when you need to add precision because double is no longer good enough? Not only do you need to find them all but then factor them out to different types.
How do you support currencies? How do you know what currency "double total_money" is at the moment? The meaning is lost as soon as you pass it to another function. Even if you are only dealing with USD right now good luck adding currency support in the future if you're using primitives.
Yes, you might have to press a key shortcut to look at the definition to see this information, but duplicating it in the variable name everywhere you use it seems barely better than comments. Furthermore, the variable names can be wrong because they're not enforced by the typesystem. The typechecker can enforce for me that I don't pass a negative value or a value in the wrong currency. Variable names don't do any enforcement
Primitive obsession[0] also tends to lead to lots of duplication of logic. Multiple functions have tests that check what happens when passed an invalid value, logic that would be in one place with a type definition.
[0] http://c2.com/cgi/wiki?PrimitiveObsession
While not really related to the primitive obsession vs domain modelling debate - it's a really bad idea to use floating point numbers for monetary calculations, and from experience I can tell you how hard it is to fix this down the road in an existing codebase processing large amounts of money.
This sort of thing is probably why such examples are always blandly about cars and their colors and shapes and their areas.