3

別の Generic を定義する必要がある Generic Type Constraint の制限について、かなり一般的なシナリオがあります。

すでに議論されていますが (Eric Lippert 自身と他の人)、これまでのところ、次のシナリオに遭遇したときに適用できる一般的なガイドラインや経験則を見ていません。

public abstract class Class<TProperty> : Class
     where TProperty : Property<>
// Sadly the line above cannot work, although the compiler could actually infer
// the Generic Type, since defining two class definitions like:
// Considering A & B two other well-defined classes
// Class<TA> where TA : A and 
// Class<TB> where TB : B is not allowed and well-understandable
{
    protected Class(TProperty property)
    {
        if (property != null)
        {
            this._property = property;
        }
        else
        {
            throw new ArgumentNullException(@"property");
        }
    }

    private readonly TProperty _property;
    public TProperty Property
    {
        get
        {
            return this._property;
        }
    }
}
public abstract class Property<TParentClass>
// Same remark goes here
    where TParentClass : Class<>
{
    protected Property(TParentClass parent)
    {
        if (parent != null)
        {
            this._parent = parent;
        }
        else
        {
            throw new ArgumentNullException(@"parent");
        }
    }

    private readonly TParentClass _parent;
    internal TParentClass Parent
    {
        get
        {
            return this._parent;
        }
    }
}

これは問題ありません。インターフェースを使用するか、次のように新しい基本クラスを作成することで、いくつかの回避策がまだあります。

public abstract class Class
{
}
public abstract class Class<TProperty> : Class
    where TProperty : Property
{
    protected Class(TProperty property)
    {
        if (property != null)
        {
            this._property = property;
        }
        else
        {
            throw new ArgumentNullException(@"property");
        }
    }

    private readonly TProperty _property;
    public TProperty Property
    {
        get
        {
            return this._property;
        }
    }
}

public abstract class Property
{
}
public abstract class Property<TParentClass>
    where TParentClass : Class
{
    protected Property(TParentClass parent)
    {
        if (parent != null)
        {
            this._parent = parent;
        }
        else
        {
            throw new ArgumentNullException(@"parent");
        }
    }

    private readonly TParentClass _parent;
    internal TParentClass Parent
    {
        get
        {
            return this._parent;
        }
    }
}

これは問題ありませんが、新しい正当な継承レイヤーを追加したい場合はどうなりますか?

public abstract class InheritedClass<TInheritedProperty> : Class<TInheritedProperty>
// Damn it! I wanted to be more specific but I cannot have <> (and also <,>, <,,>, etc.)
// Cannot do that without declaring another public interface... sad
// Or another non generic base class
    where TInheritedProperty : Property
{
    // But this remark cannot work here... I would have needed a "real" type not InheritedProperty<>...
    // Yeah this is it: starting to bake the noodles
    protected InheritedClass(TInheritedProperty property)
        : base(property)
    {
    }
}

public abstract class InheritedProperty<TInheritedClass> : Property<TInheritedClass>
// Same goes here
    where TInheritedClass : Class
{
    protected InheritedProperty(TInheritedClass parent)
        : base(parent)
    {
    }
}

またはさらに悪いことに (コードが明らかにコンパイルできない場合)、実際のタイプ セーフがない状態で非常に愚かになります。

public abstract class InheritedClass2<TInheritedProperty, TInheritedPropertyClass> : Class<TInheritedProperty>
    where TInheritedProperty : InheritedProperty2<TInheritedPropertyClass, TInheritedProperty>
{
    protected InheritedClass2(TInheritedProperty property)
        : base(property)
    {
    }
}

public abstract class InheritedProperty2<TInheritedClass, TInheritedClassProperty> : Property<TInheritedClass>
    where TInheritedClass : InheritedClass2<TInheritedClassProperty, TInheritedClass>
{
    protected InheritedProperty2(TInheritedClass parent)
        : base(parent)
    {
    }
}

その時点で、人々は通常ノーと言います。設計はそれほど複雑ではありません...ビジネス要件を確認し、コンポジションとの大規模なインターフェースを使用するだけです。継承は、追加のコードを書くために節約するためだけではなく、それらのクラスは何らかの形を形成する必要があります家族の中で、彼らは親切な家族を形成しています。

十分に公平ですが、これは私が告白しなければならない状況を実際に解決するものではありません。

はい、それらはあなたを本当に夢中にさせ（再帰的制約など）、髪の毛を引っ張らせる可能性があります...しかし、特にタイプセーフに関しては、これが便利な状況があります。

とにかく、これらの制約に関して、トラックに戻るために従うべき最も適切で一般的なガイドラインは何ですか?インターフェイスを使用するか、コンストラクターでタイプサブセットを選択する以外の解決策はありますか?

4

2 に答える 2

1

以前、C# で非常に複雑なアプリケーション モデルを超テンプレート化しようとしたときに、同様の問題に遭遇したことがあります。私は、コンパイラができることは限られているという結論に達しました。

特に型引数で何かをする必要がある場合にのみ、非常に複雑な型制約を設定することについて心配します。たとえば、それを反復処理するため、それが であることを保証する必要があるとします。これらの例の場合、型制約はまったく必要ありません。IEnumerableClass

ただし、型の制約を維持することがどうしても必要であることがわかった場合は、次のように、反分散と共分散を利用して子型を制約することができます。

class Foo<TProperty> : Class
    where TProperty : IProperty<object>
{
    // Same as your implementation
}

interface IProperty<out T>
{
    T Property;
}

class Property<T> : IProperty
{
    // Same as your implementation
}

編集:反分散と共分散は、実装ではなくクラス インターフェイスでのみ定義できるため、IProperty インターフェイスを追加しました。

于 2015-08-23T10:58:47.623 に答える