OOPでのFPのストレッチ

しばらく前、機能的な世界で6か月の休暇を過ごした後、PLOに戻った後、いつものレーキを何度も繰り返しました。誤って状態を変更しました。

private double fBm(Vector2D v, int y) { double result = 0f; double freq = Frequency; for (int i = 0; i < Octaves; ++i) { result += NoiseFn(permutation, v * freq) * Amplitude; freq *= Lacunarity; Amplitude *= Gain; // <--  . } return result; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

FPでは、特にこのようなバグを取得する必要がありますが、一部の言語では原則として不可能です。 有用な仕事からのサラダとクラスの状態は喜ばれませんでした、この4行でもエラーの範囲は広すぎます。 私はこれらの熊手の面積を減らす方法を考え始めました、そして、私は以下を推測しました：

まず、 this



必須にする必要があります。 式の間違った側にフィールドを置くのは簡単すぎます。 どこにでも文脈を明確に示していたら、すぐに足を踏み入れたことに気づいたでしょう。 残念ながら、C＃コンパイラはこれを強制することはできません。また、静的なスタジオチェックでは、逆に機能するルールのみがあります。つまり、これを強制的に削除します。 だから、どうやら、独自に作成する必要があります。

次に、メソッド本体からクラスフィールドの使用を除外し、メソッドの最後にすべての変更を記録する必要があります（存在する場合）。 3つの段落があります。 最初に必要なものすべてを発表し、2番目に有用な作業を行い、3番目に状態を維持します。

 public void DoAThing(int input) { //   int a = this.A; int b = this.B; int result = 0; //   for (int i = 0; i < input; ++i) result += (a + b) * i; //   this.Thing = result; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初の段落では、必要なすべての状態がローカルに保存されます。

2番目では、 this



は表示されません。

3番目では、 this



は常に最初の単語でなければなりません。 状態を変更する他のメソッドはすぐに呼び出されます。

return



はどこにでも追加できますが、メソッドの動作には影響しません。

長所

• 状態がランダムに変化するバグは少なくなります。
• 3番目の段落がないため、メソッドは純粋な関数になります。つまり、メソッドを並行して実行できます。

短所

• しつけ。 ふふふ。 自動チェックがなければ、すべてを簡単に台無しにしてしまいます。
• 場合によっては、このアプローチの動作はより遅くなります。
• 奇妙に見えるか、愚かに見えるかもしれません。 以下に例を示します。

 { int a = this.A; int b = this.B; return a + b; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

結論の代わりに

どう思いますか？ それは理にかなっていますか、私は心配していますか？ すでにこれを行っているか、OOPでAFの他の部分をプルしている場合は、共有してください。