I have a project with many calculations involving a lot of real world units :
- Distance;
- Temperature;
- Flow rate;
- ...
This project involves complicated and numerous calculation formulas.
That's why I supposed the use of custom types like Temperature, Distance... can be good for code readability. For example:
Temperature x = -55.3;
Meter y = 3;
or
var x = new Temperature(-55.3);
I tried to make a Temperature class that uses a double internal value.
public class Temperature
{
double _Value = double.NaN;
public Temperature() { }
public Temperature(double v) {
_Value = v;
}
public static implicit operator Temperature(double v) {
return new Temperature(v);
}
}
But class are nullable. This mean that something like :
Temperature myTemp;
is "correct" and will be null. I dont want this. I dont want to use structs because they are too limited :
- They cannot use parameterless constructor nor instance field intializers like
double _Value = double.Nan;
to define a default value (I wand default underlying double value to be NaN) - They cannot inherits from classes, they only can implement Interfaces
Them I wonder whether there is a way to tell C#:
Temperature myTemp = 23K; // C# does not implement anything to make K unit...
but I know C# does not handle no custom units.
Temperature myTemp = new Kelvin(23); // This might work
So I imagine I could create two Celsius and Kelvin classes that inherits from Temperature, and then I started to wonder if the idea really worth it, because it involves a lot of coding and testing.
That's the discussion I would like to start :
Would the use of real world units in my code instead of .NET types would be a good thing or not ? Did anyone this already ? What are the pitfalls and the best practices ? Or should I better keep stay away from this and use standard .NET types ?
One way to achieve this would be to use composition of the basic object (
Temperature
in your case) with aTemperatureTraits
class that specializes the basic object. By analogy to C++, theString
equivalent classbasic_string
is actually a class template (generic in C# terms) that has template parameters not only for the string element (char
, wide char) but also a traits class that elaborates on how the class behaves for a given type of string element (e.g.char_traits
).In your case, you might define a generic like
public class MeasurableWithUnits<class M MEASURABLE, class U UNITS>
and then implementation would depend not only on the measurable class but also on the units class. How useful this would be in practice would depend on how much of such an object could be made truly generic - what operations are common across combinations of
Measurable
andUnits
?There is a research paper on C# traits here, if this approach looks interesting.
I think it can be good when you want to add more specific functionality to a temperature (for example:
IsFreezing()
).To solve the issue with Kelvin and Celsius: make an interface
ITemperature
and a baseclass. In the baseclass, you can implement the interface and fill in the details that are the same for all classes.I don't think it's worth adding static types for units in C#. You would need to overload so many operators(for all unit combinations, not just for all units). And build in functions like Math.Sqrt work on normal doubles,...
What you might try is using dynamic types:
And then when compiling in debug mode add checks if the units fit together. And in release just remove the PhysicalUnit field and all the checks, and you're (almost) as fast as code using normal doubles.
If you use a struct, then this cannot be
null
I would make
Temperature
an abstract class that stores the temperature (in Kelvin!) in an InternalTemperature property.A derived class
Celcius
would translate the input value internaly to Kelvin. It would have a (readonly) Value property that translated the internal value back.Comparing them (is one warmer than the other) would then be easy.
Why not try a struct that looks like this:
Then use it like, say, this: