我有一个项目,其中涉及许多实际单位的计算:
- 距离;
- 温度;
- 流速;
- ...
该项目涉及复杂且众多的计算公式。
这就是为什么我认为使用温度、距离等自定义类型可以提高代码的可读性。例如:
Temperature x = -55.3;
Meter y = 3;
或者
var x = new Temperature(-55.3);
我试图制作一个使用双内部值的温度类。
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);
}
}
但是类是可以为空的。这意味着类似:
Temperature myTemp;
是“正确的”并且将为空。我不想要这个。我不想使用结构,因为它们太有限了:
- 他们不能使用无参数构造函数,也不能使用实例字段初始化
double _Value = double.Nan;
器来定义默认值(我希望默认的基础双精度值是 NaN) - 它们不能从类继承,只能实现接口
他们我想知道是否有办法告诉 C#:
Temperature myTemp = 23K; // C# does not implement anything to make K unit...
但我知道 C# 不处理任何自定义单位。
Temperature myTemp = new Kelvin(23); // This might work
所以我想我可以创建两个继承自 Temperature 的 Celsius 和 Kelvin 类,然后我开始怀疑这个想法是否真的值得,因为它涉及大量的编码和测试。
这就是我想开始的讨论:
在我的代码中使用真实世界的单位而不是 .NET 类型会是一件好事吗?有人已经这样做了吗?有哪些陷阱和最佳实践?或者我应该最好远离这个并使用标准的 .NET 类型?