C＃での構造型付け

Go言語を勉強したとき、メソッドシグネチャへのインターフェイスのキャストのアイデアが本当に好きでした（型システムの残りの部分はあまり好きではなく、あまりにも原始的でした）。 これは静的なカモタイピングです！ 科学： 構造の類型化 。



考えてみると、このアプローチには多くの欠点があります。実装の複雑さから、リスコフの置換原則の違反までです。 実際、クラスに目的の署名（名前を含む）を持つメソッドがある場合、これはこのメソッドが期待どおりに動作することを意味するものではありません。

したがって、C＃を含む主流言語では、構造型指定はサポートされていません。 これとおとぎ話が終わるように思われます。 しかし最近、私が現在取り組んでいるプロジェクトでは、構造タイピングが使用されていることに気付きました。 カットの下の詳細。



プロジェクトでは、このメソッドを使用してゲッター/セッターを操作します。 もちろん、それは従来の方法にも使用できますが、これは良いことをもたらす可能性は低いです。



だから。 同じプロパティ（名前とタイプ）の多くを持つクラスのセットがあると想像してください。

そして、これらのプロパティからのデータが機能するためにさらに多くのクラスが必要です。 たとえば、自動プロパティA、B、およびCを含むDataItemクラスがあります。また、プロパティAの値を基にして何かを計算し、Bに入れるにはCalculatorクラスがあります。しかし、Cについて知る必要はありません。 また、彼はDataItemクラスについて知る必要はありません。 AおよびBを持つ他のクラスで使用できます。



これを実装する方法は？ 事前に、これらのプロパティごとにインターフェイスを宣言し、対応するインターフェイスを実装するなどのプロパティで各クラスをマークします。 そして、コンシューマクラスメソッドをジェネリックとして宣言します。



実装：

interface PropertyA{ int A {get; set;} } class DataItem: PropertyA, PropertyB, PropertyC{ public int A {get; set;} public bool B {get; set;} public string C {get; set;} } ... void Calculate<T>(T data) where T: PropertyA, PropertyB{ data.B = data.A > 0; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

簡単です：ジェネリックパラメーターの制限を指定することで、適切なフィールドセットを収集でき、それらを実装するクラスのオブジェクトは、何の削減もなくそのようなメソッドに転送できます。



なぜこれが便利になるのか、また同様の手法が必要な状況がコードの別の臭いであるかどうかを理解するのはさらに困難です。