>upd: after thinking a bit about how to "architect" a general conversion calculator, I'd probably go for 2 step process to convert into rational numbers for a decided upon base measure, with 2 methods (mostly for readability, as one is the inverse of the other with the same factor) for each unit: "toStandard" + "fromStandard" and the multiplicator/factor for that unit/scale as a property. Instead of the property another method to look up that value from a table (memory as in hash or disk like in SQL) could be used - although I'd probably cache the lookup access, pipe into memory hash or inject the value at compile time if using a disc based table for maintainance ease. Conversions into more than 1 scale/ not into decimal system would be programmed as a wrapper calling a sequence of such tiny conversion classesfunctions, probably via a template pattern.
>
>Imagine having to code and maintain a conversion calculator for many units like:
>http://www.convert-me.com/en/convert/weight/
>and encountering a switch as basic pattern ;-))

And there you also have the inverse measures, like liters per 100km vs miles per gallon, or the calibre in millimeters vs how many balls of that diameter can be poured out of a pound of lead. Even the dimensionless values can be weird - volume percentage of alcohol vs proof.

>The basic computation pattern here is a dynamic value/hash/lookup access for the base ratio, and unDRY bulldozing with a switch is...

For most conversions, I still use my favorite calculator, Calc98, written in Fortran - and it still works, eight motherboards and seven windowses later.