Something which is conspicuously missing from the .Net Framework is a Money class for runtime calculations on currency amounts. Such a class’s primary purpose would be to eliminate the round-off errors that you see when using float or double for money amounts, as well as providing runtime checks against adding or subtracting two money amounts with different currencies.   (There actually is a class called Money in the framework,  but it’s for SQL Server money type columns, not for doing calculations on amounts).  What I’m talking about is the ability to do something like:

MoneyAmount m = new MoneyAmount();
m.CurrencyInfo = CurrencyInfo.USD;
m.Cents = 9995;

MoneyAmount m2 = new MoneyAmount();
m2.CurrencyInfo = CurrencyInfo.CAD;
m2.Cents = 1120;

MoneyAmount m2InUSD = m2.ConvertTo(CurrencyInfo.USD);

MoneyAmount m3 = m1 + m2InUSD;

m3 would then contain an amount in USD cents that could be formatted for display or stored in a database or whatever.

There are lots of 3rd party implementations for a Money class for most languages and frameworks, but all of them face a similar set of challenges:

1. How to deal with currency conversions. Should the conversion be explicit or implicit?  Should developers have to check for currency match before every arithmetic operation they do on two money objects? Or should they expect the class to do the conversion for them?  If the class does the conversion for them, which currency should it convert to?  The one that comes first?  That could be confusing.
   Also, in my example above, I used the property Cents to express the smallest integral value of the currency type, but not every currency has something analogous to “Dollars” and “Cents” (the most obvious example being Japanese Yen, but also is the case with Turkish Lira, Lebanese Lira … and, well, pretty much anything called Lira, actually).  How to deal with these inconsistencies is also an important design decision (especially since the conversion rate is usually given between dollars and yen, but the amounts stored might be cents and yen, changing the conversion rate by a factor of 100).
2. Where to store conversion rates. A more flexible framework would allow the developer to pass the conversion rate when they ask for the currency to be converted.  However, this would introduce some annoying overhead to writing code that does lots of conversions.  But, any common structure that stored conversion rates inside the class would need to be made thread-safe.  Also, conversion rates need to be updated regularly, perhaps even multiple times a day, depending on the application.
3. Which arithmetic operations to allow. Adding and subtracting money amounts is something which makes sense, but multiplying or dividing two money amounts probably doesn’t.  So addition and subtraction would be defined between money amounts, but multiplication and division are only defined between a money amount and a scalar numeric value (yielding another money amount). I’m not really sure if modulus makes any sense at all, but it might in some applications.  Again, this is something which would vary from one application to the next.
4. Round off. If you’re calculating interest or any type of operation where you take a percentage of the money amount, you’re going to have decimal cents laying around.  What happens to them is either a matter of business process or legal requirement, although I suppose you could always transfer them to a personal account.

This list really illuminates the reason why these classes aren’t built-in to major frameworks.  There’s a lot of design decisions that can only be made with information about the context in which the class would be used.  Frameworks should try to stick to doing things that they can do well, and things that they can do right for more than 90% of the expected uses.  There’s just too much customization that has to go on with a money amount class.  So, roll your own.

August 8th, 2008 | Tags: frameworks, refactoring | Subscribe to comments | Leave a comment | Trackback URL