c# - 当一个结构最终成为约束时(由于接口(interface)-编译器变得脾气暴躁)，该怎么办？

Question

编辑：
我的结论是不可能满足我所有的要求！
原始问题…
我似乎陷入了一个不幸的困境。归根结底，结构不是有效的泛型约束，这是完全正确的，但问题却不是越少…
为什么要将泛型约束到结构？是吗？
我真的不想这么做-这是界面设计的结果。
我将通过这个过程来解释我的困境：
假设我有一个与某些（潜在的）性能关键通用方法的接口，即：

interface ISomeInterface
{
    Result RelativeComputation(ISomeInterface other);
}

但是 ISomeInterface本身并不是一个足够强的约束：我希望使这个计算成为可能的实现细节-我特别不希望在接口本身中公开所需的数据，因为它只需要一个方法，更糟糕的是，所需的数据是泛型的（该类型在该接口或任何相关接口的任何其他地方都没有使用），因此将其公开会在使用 ISomeInterface的每个其他接口或类中添加额外的泛型。
因此，要解决上述问题，代码的下一个逻辑演变是：

interface ISomeInterface<T> where T : ISomeInterface<T>
{
    Result RelativeComputation(T other);
}

现在不需要公开实现细节，约束很强，在大多数情况下，这将是一个圆满的结局。
但是，当 T由另一个接口实现时，可能会出现以下情况：

interface IOtherInterface : ISomeInterface<IOtherInterface>
{
    //... *other stuff*
}

现在又有问题了！：。（
首先，正如前面提到的，这个方法调用可能以性能关键型代码结束，因此在这些情况下，最好将 other参数设置为结构。然而，随着上面的代码，这将不可避免地被拳击毁了。
其次， T中对 RelativeComputation(T other)的约束看起来很强，但实际上太弱了，除非我们再次选择公开实现细节！（如前所述直接在 ISomeInterface中，或在 IOtherInterface中）
第二个问题我没有一个好的解决方案，除了使 IOtherInterface成为泛型并在其上应用奇怪的重复模板模式，然后再次添加计算方法。结果是：

interface IOtherInterface<T> : ISomeInterface<IOtherInterface<T>>
    where T : IOtherInterface<T>
{
    new Result RelativeComputation(T other);
    //... *other stuff*
}

…最终继承层次结构将达到一个具体的类型，实现细节将保持隐藏。
这固然不是很优雅，但也不是真正的问题，所以我离题了。
真正的问题是上面提到的“第一个”问题。
乍一看，它似乎很容易解决；使方法本身通用，如下所示：

interface ISomeInterface<T> where T : ISomeInterface<T>
{
    Result RelativeComputation<T2>(T2 other) where T2 : T;
}

现在参数可以是一个结构，不再有拳击了！
（即使上面的 T是一个接口，例如 IOtherInterface，也是如此）
太好了！
所以让我们做一个合适的结构，即实现 ISomeInterface（或者更派生的接口，如 IOtherInterface），问题是，eeh…哦。
如果您还没有弄清楚，下面是该代码的外观：

struct MyPerformantStruct : ISomeInterface<MyPerformantStruct>
{
    Result RelativeComputation<T2>(T2 other) where T2 : MyPerformantStruct; // nope! :(
}

这个接口需要那个确切的签名，但不能编译！
我希望有办法解决这个问题？
（允许结构没有拳击和隐藏尽可能多的实现！）
为了澄清这一点，我并不期望有一种方法可以将结构用作通用约束，而是希望有另一种解决方法，比如聪明的设计改进（和/或黑客）。
编辑：
目前的回答和评论让我深入了解了一些其他相关信息：
接口和实现类型可以位于不同的程序集中。（接口在库中。）
我并不是说它必须是一个结构，我是说应该使用一个类或者一个结构（没有拳击）。
我所指的“实现细节”是某种值类型（可能不止一种）。该方法是一种 bool IsLessThan(...)类型的方法，在没有装箱、解压和运行时检查的情况下，我似乎无法评估（不，谢谢！）-或者不知道底层类型的实现细节，也不公开接口中的那些细节，从而锁定实现并破坏整个抽象点——或者将其限制在接口级别，这有上面提到的其他问题——或者也将其限制在方法级别，这正是我上面想要做的，但事实证明，它显式地阻止了 T成为一个结构。
（我更喜欢呆在.NET3.5上，但这并不重要。）
我的问题描述很长，不清楚为什么在接口和方法上都需要泛型，所以我将提供一个代码示例并说明为什么它不编译（或者需要运行时转换）：
此代码说明了约束到实际类型的必要性：

interface IExample
{
    bool IsLessThan<T>(T other) where T : IExample;
}

class ExampleClass : IExample
{
    short someValue;
    public bool IsLessThan<T>(T other) where T : IExample
    {
        return this.someValue < other.???; // <-- what now?
    }
}

Answer 1

首先，你应该问一个关于你正在解决的实际问题的问题。如果你只举例子，很难理解你想做什么，为什么要这么做。也许你处理问题错了，或者你的实际问题有更好的解决方案。有无数的设计模式可以解决许多问题。
看起来你在做微观优化。你量过有关的代码了吗？你找到瓶颈了吗？
你想要这样的代码：

struct MyPerformantStruct : ISomeInterface<MyPerformantStruct>
{
    Result RelativeComputation<T2>(T2 other) where T2 : MyPerformantStruct;
}

但是…为什么？如果 MyPerformantStruct是一个结构，那么根据定义，没有任何类或结构可以从它继承。唯一能满足 T2的类型是… MyPerformantStruct。那为什么不直接用呢？

interface ISomeInterface<T>
    where T : struct
{
    Result RelativeComputation(T other);
}

struct MyPerformantStruct : ISomeInterface<MyPerformantStruct>
{
    Result RelativeComputation(MyPerformantStruct other);
}

是否有原因 T是类型上的泛型参数而不是成员上的泛型参数？

interface ISomeInterface
{
    Result RelativeComputation<T>(T other)
        where T : struct;
}

struct MyPerformantStruct : ISomeInterface
{
    Result RelativeComputation<MyPerformantStruct>(MyPerformantStruct other);
}

您的代码是否不能处理除结构之外的其他内容？在我看来不太可能，所以你可以取消 struct约束。当 T是一个结构时，您仍然可以获得未绑定结构的好处。

interface ISomeInterface
{
    Result RelativeComputation<T>(T other);
}

struct MyPerformantStruct : ISomeInterface
{
    Result RelativeComputation<MyPerformantStruct>(MyPerformantStruct other);
}

你确信你能在不装箱的情况下处理这个结构吗？如果不是，那么您最好对类型进行抽象并请求结构的接口，或者如果您真的想这样做的话， object。我猜使用structs的唯一原因是性能。这是错误的做法。结构应该表示不可变的值，例如日期/时间对或百分比。结构不是用于性能原因的可变字段的无框集合。如果你试着这样使用它们，你以后会遇到问题的。