リスコフ代替の原則と契約

契約を扱う際には、回避しなければならない不快なことがいくつかあります。 たとえば、契約開発者が遵守するリスコフ代替原則は、夜には言及されません。





たとえば、外部ライブラリからインターフェイスを継承する特定のクラスがあります。 そして、このインターフェイスのメソッドの実装をクラスで定義します。

public class A : Interface1 { public void MethodInterface1( object sender, Event e) {...} }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、待ち伏せは、上記の原則に従っていることです-着信値を直接チェックしないでください。 それは、ライブラリ、インターフェイスプロバイダーの事後条件の責任です。 つまり 同様のコードは正しくないと見なされます。

 public void MethodInterface1( object sender, Event e) { Contract.Requires(sender != null, "Sender is null"); Contract.Requires(event != null, "Event object is null"); ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さらに、そのような実装でも警告が生成されます（警告CC1033）：

 public void MethodInterface1( object sender, Event e) { if (sender == null) throw new ArgumentNullException("sender", "Event sender is null."); if (evt == null) throw new ArgumentNullException("evt", "Event object is null."); Contract.EndContractBlock(); ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

どうやら、開発者は、インターフェイスの作成者が継承のルールと階層の理論について通常よりも少し理解することを願っています...



PS。 同様の継承されたインターフェースの処理では、契約の代わりに古い検証方法を使用して、契約仕様を削除する必要があります。