包装System.Math是个坏主意吗？

Question

我有自己的数学库,我希望它被称为"数学"(我一直称它为"数学").它位于自己的命名空间中,但类名为"Math"仍然与System.Math冲突.我解决这个问题的方法是在System.Math中为我的库添加一个包装器,它只显式调用System.Math函数,然后我必须添加

using Math = Yushatak.Libraries.Math;

到每个使用Math.*功能的文件.我不觉得这是最好的方法,我也担心包装会造成额外的开销,而且这不是你想要开销的地方..

建议吗？有没有更好的方法来"扩展"System.Math？这只是一个坏主意,我应该回到"数学"？有什么建议吗？:P

包装方法示例:

    public static decimal Abs(decimal value)
    {
        return System.Math.Abs(value);
    }

Answer 1

这个答案现在有三个不同的部分.

虽然using声明方法除了源代码中的一个额外行之外没有任何开销,但是包装器方法会以多种方式产生开销.

1. 有很多方法System.Math.准确地再现包装纸充其量是乏味的.
2. 运行时的性能开销可能从无关紧要到严重,具体取决于JIT如何在内部处理对数学函数的调用.这可能因实施和平台而异.
3. 您的类的编译代码将更大.
4. 更难理解数学类中的哪些功能是新功能,哪些只是已经存在的东西的包装器.

通过使用不同的策略可以防止上述所有情况.

通常的做法是故意避免名称冲突我命名新类NameEx,Name原始名称在哪里.例如,您将有兴趣创建该类MathEx.

您还可以使用以下内容来处理冲突的名称.

using Math = Yushatak.Libraries.Math;
using SystemMath = System.Math;

这在Visual Studio扩展开发中经常发生,特别是对于名为Constants和的类IServiceProvider.