具有约束层次结构的泛型 [英] Generics with constraints hierarchy

问题描述

  interface IStateSpace< Position，Value> 
其中位置：IPosition //<  - 问题从这里开始
其中Value：IValue //<  - 因为我没有
 {//知道如何离开这个
 //循环依赖！ 
 //注意我应该是
 //定义泛型参数
 //在这里，但是我不能！ 
值GetStateAt（位置位置）; 
 void SetStateAt（Position position，State state）; 
 
 $ / code> 

当你在这里时， IPosition ， IValue 和 IState 互相依赖。我该如何摆脱这种困境？我想不出任何其他设计能够绕过这种循环依赖，并且仍然准确地描述我想要做的事情！

 接口IState< StateSpace，Value> 
其中StateSpace：IStateSpace //问题
其中值：IValue //问题
 {
状态空间状态空间{get; }; 
 Value Value {get;组; } 
} 
 
接口IPosition 
 {
} 
 
接口IValue<状态> 
其中State：IState {//这里我们再次遇到问题
 State State {get; } 
} 
  

基本上我有一个状态空间 IStateSpace 里面有状态 IState 。它们在状态空间中的位置由 IPosition 给出。每个州有一个（或多个）值 IValue 。我简化了层次结构，因为它比描述的要复杂一些。使用泛型定义此层次结构的想法是允许相同概念的不同实现（ IStateSpace 将作为矩阵作为图形实现，等等）。

我可以逃避这个吗？你通常如何解决这类问题？在这些情况下使用哪种设计？

谢谢 解决方案

这个问题并不完全清楚 - 是的，你在泛型类型中有循环依赖，但是工作起来。



我有一个类似的问题 协议缓冲区：我有消息和建设者，他们成对出现。因此，接口如下所示：

  public interface IMessage< TMessage，TBuilder> 
其中TMessage：IMessage< TMessage，TBuilder> 
其中TBuilder：IBuilder< TMessage，TBuilder> 
  

和

  public interface IBuilder< TMessage，TBuilder> ：IBuilder 
其中TMessage：IMessage< TMessage，TBuilder> 
其中TBuilder：IBuilder< TMessage，TBuilder> 
  

这确实很丑，但它很有用。你想表达什么，你目前无法表达？您可以在我的博客上看到我对这个的一些想法。 （关于协议缓冲区的系列文章的第2部分和第3部分是与这里最相关的。）

（顺便说一句，如果您要添加一个 T 前缀到您的类型参数中。目前它看起来像 State 和 Value 只是类。）

I am currently facing a very disturbing problem:

interface IStateSpace<Position, Value>
where Position : IPosition           // <-- Problem starts here
where Value : IValue                 // <-- and here as I don't
{                                    //     know how to get away this
                                     //     circular dependency!
                                     //     Notice how I should be
                                     //     defining generics parameters
                                     //     here but I can't!
    Value GetStateAt(Position position);
    void SetStateAt(Position position, State state);
}

As you'll down here, both IPosition, IValue and IState depend on each other. How am I supposed to get away with this? I can't think of any other design that will circumvent this circular dependency and still describes exactly what I want to do!

interface IState<StateSpace, Value>
where StateSpace : IStateSpace        //problem
where Value : IValue                  //problem
{
    StateSpace StateSpace { get; };
    Value Value { get; set; }
}

interface IPosition
{
}

interface IValue<State>
where State : IState {      //here we have the problem again
    State State { get; }
}

Basically I have a state space IStateSpace that has states IState inside. Their position in the state space is given by an IPosition. Each state then has one (or more) values IValue. I am simplifying the hierarchy, as it's a bit more complex than described. The idea of having this hierarchy defined with generics is to allow for different implementations of the same concepts (an IStateSpace will be implemented both as a matrix as an graph, etc).

Would can I get away with this? How do you generally solve this kind of problems? Which kind of designs are used in these cases?

Thanks

解决方案

It's not entirely clear what the problem is - yes, you've got circular dependencies in your generic types, but that works.

I have a similar "problem" in Protocol Buffers: I have "messages" and "builders", and they come in pairs. So the interfaces look like this:

public interface IMessage<TMessage, TBuilder>
    where TMessage : IMessage<TMessage, TBuilder> 
    where TBuilder : IBuilder<TMessage, TBuilder>

and

public interface IBuilder<TMessage, TBuilder> : IBuilder
    where TMessage : IMessage<TMessage, TBuilder> 
    where TBuilder : IBuilder<TMessage, TBuilder>

It's certainly ugly, but it works. What do you want to be able to express that you can't currently express? You can see some of my thoughts about this on my blog. (Parts 2 and 3 of the series about Protocol Buffers are the most relevant here.)

(As an aside, it would make your code more conventional if you would add a T prefix to your type parameters. Currently it looks like State and Value are just classes.)

这篇关于具有约束层次结构的泛型的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！