Javaの優れたスタイル（インスタンス変数と戻り値）

クラスのいくつかのメソッドで共通のデータを使用する必要がある場合、これらの2つの方法のどちらを使用するかを決めるのに苦労することがよくあります。より良い選択は何でしょうか？

このオプションでは、インスタンス変数を作成して、追加の変数を宣言する必要を回避し、メソッドパラメーターの定義を回避することもできますが、これらの変数がインスタンス化/変更される場所はそれほど明確ではありません。

public class MyClass {
    private int var1;

    MyClass(){
        doSomething();
        doSomethingElse();
        doMoreStuff();
    }

    private void doSomething(){
        var1 = 2;
    }

    private void doSomethingElse(){
        int var2 = var1 + 1;
    }

    private void doMoreStuff(){
        int var3 = var1 - 1;
    }
}

または、ローカル変数をインスタンス化して引数として渡すだけですか？

public class MyClass {  
    MyClass(){
        int var1 = doSomething();
        doSomethingElse(var1);
        doMoreStuff(var1);
    }

    private int doSomething(){
        int var = 2;
        return var;
    }

    private void doSomethingElse(int var){
        int var2 = var + 1;
    }

    private void doMoreStuff(int var){
        int var3 = var - 1;
    }
}

答えが両方とも正しいという場合、どちらがより頻繁に表示/使用されますか？また、各オプションに長所/短所を追加できる場合は非常に価値があります。

私はこれがまだ言及されていないことに驚いています...

var1実際にオブジェクトの状態の一部であるかどうかによって異なります。

あなたは、これらのアプローチの両方が正しく、それが単なるスタイルの問題であると仮定します。あなたは間違っている。

これは完全に適切にモデル化する方法に関するものです。

同様に、オブジェクトの状態privateを変更するインスタンスメソッドが存在します。それがあなたのメソッドがしていることではない場合、そうでなければなりませんprivate static。

どちらがより一般的かはわかりませんが、常に後者を使用します。データフローとライフタイムをより明確に伝え、初期化中にのみ関連するライフタイムを持つフィールドでクラスのすべてのインスタンスを肥大化することはありません。前者は紛らわしいだけで、コードのレビューが非常に困難になると思います。なぜなら、どのメソッドも変更される可能性を考慮する必要があるからvar1です。

範囲を縮小する必要があります変数をあります（そして合理的です）。メソッドだけでなく、一般的に。

つまり、変数がオブジェクトの状態の一部であるかどうかによって異なります。はいの場合、そのスコープ、つまりオブジェクト全体で使用しても問題ありません。この場合、最初のオプションを使用します。いいえの場合、2番目のオプションを選択すると、変数の可視性が低下し、全体的な複雑さが軽減されます。

Javaの優れたスタイル（インスタンス変数と戻り値）

別のスタイルがあります-コンテキスト/状態を使用します。

public static class MyClass {
    // Hold my state from one call to the next.
    public static final class State {
        int var1;
    }

    MyClass() {
        State state = new State();
        doSomething(state);
        doSomethingElse(state);
        doMoreStuff(state);
    }

    private void doSomething(State state) {
        state.var1 = 2;
    }

    private void doSomethingElse(State state) {
        int var2 = state.var1 + 1;
    }

    private void doMoreStuff(State state) {
        int var3 = state.var1 - 1;
    }
}

このアプローチには多くの利点があります。状態オブジェクトは、たとえば、オブジェクトとは独立して変更でき、将来のために多くのゆらぎを与えます。

これは、コール間で一部の詳細を保持する必要がある分散/サーバーシステムでもうまく機能するパターンです。ユーザーの詳細、データベース接続などをstateオブジェクトに保存できます。

それは副作用についてです。

var1状態の一部であるかどうかを尋ねることは、この質問のポイントを見逃します。var1永続化する必要がある場合は、インスタンスでなければなりません。永続性が必要かどうかにかかわらず、どちらのアプローチも機能するようにできます。

副作用アプローチ

一部のインスタンス変数は、呼び出しから呼び出しへのプライベートメソッド間の通信にのみ使用されます。この種のインスタンス変数は、存在しないようにリファクタリングできますが、そうする必要はありません。時には物事がより明確になります。しかし、これにはリスクがないわけではありません。

変数は2つの異なるプライベートスコープで使用されるため、そのスコープから変数を解放しています。配置するスコープで必要なわけではありません。これはわかりにくいかもしれません。「グローバルは悪です！」混乱のレベル。これは機能しますが、うまくスケールしません。それは小さなでのみ動作します。大きなオブジェクトはありません。長い継承チェーンはありません。ヨーヨー効果を引き起こさないでください。

機能的アプローチ

現在、var1何も持続する必要がない場合でも、パブリックコール間で保持する状態に到達する前にすべての一時的な値を取得する必要がある場合は、使用する必要があります。つまり、まだ設定できますvar1、より機能的なメソッドを使用するだけでインスタンスをます。

状態の一部であるかどうかにかかわらず、どちらのアプローチも使用できます。

これらの例では、 'var1'がカプセル化されているため、デバッガーはそれが存在することを認識しています。あなたは私たちを偏らせたくないので、あなたはそれを意図的にやったと思います。幸いなことに、私はどちらを気にしません。

副作用のリスク

とはいえ、あなたの質問はどこから来たのか知っています。私は悲惨なヨーヨーの下で働いてきました、複数のメソッドの複数のレベルでインスタンス変数を突然変異させる継承のており、それを追いかけようとしてきました。これがリスクです。

これが私をより機能的なアプローチへと駆り立てる痛みです。メソッドは、その依存関係と出力をその署名に記録できます。これは強力で明確なアプローチです。また、プライベートメソッドに渡すものを変更して、クラス内でより再利用できるようにすることもできます。

副作用の利点

制限もあります。純粋な関数には副作用はありません。それは良いことですが、オブジェクト指向ではありません。オブジェクト指向の大部分は、メソッド外のコンテキストを参照する機能です。ここでグローバルを漏らさずにそれを行うことは、OOPの強みです。グローバルの柔軟性は得られますが、クラスにうまく含まれています。必要に応じて、1つのメソッドを呼び出して、すべてのインスタンス変数を一度に変更できます。その場合、少なくともメソッドに名前を付けて、それが何であるかを明確にする名前を付ける必要があります。そうすれば、人々は驚かないでしょう。コメントも役立ちます。これらのコメントは「事後条件」として形式化される場合があります。

機能的なプライベートメソッドの欠点

機能的アプローチにより、依存関係が明確になります。純粋な関数型言語でない限り、隠された依存関係を排除することはできません。メソッドのシグネチャだけを見ても、それがコードの残りの部分で副作用を隠していないことはわかりません。あなただけではありません。

ポスト条件

あなた、そしてチームの他の全員が、副作用（事前/事後条件）をコメントで確実に文書化すれば、機能的アプローチから得られる利益ははるかに少なくなります。ええ、私は夢を見ます。

結論

個人的には、可能であればどちらの場合でも機能的なプライベートメソッドを使用する傾向がありますが、正直なところ、それらの前後の条件付き副作用コメントは、古くなった場合やメソッドが間違った方法で呼び出された場合にコンパイラエラーを引き起こさないためです。副作用の柔軟性を本当に必要としない限り、物事が機能することを知りたいだけです。

最初のバリアントは直感的ではなく、私にとって潜在的に危険に見えます（何らかの理由で誰かがプライベートメソッドをパブリックにすることを想像してください）。

クラス構築時に変数をインスタンス化するか、引数として渡します。後者は、機能的なイディオムを使用するオプションを提供し、包含オブジェクトの状態に依存しません。

オブジェクトの状態、および2番目の方法が優先される場合についての回答が既にあります。最初のパターンの一般的なユースケースを1つだけ追加します。

最初のパターンは、クラスが行うことのすべてがアルゴリズムをカプセル化することである場合に完全に有効です。この使用例の1つは、アルゴリズムを単一のメソッドに書き込んだ場合、大きすぎることです。したがって、それをより小さなメソッドに分解してクラスにし、サブメソッドをプライベートにします。

パラメータを介してアルゴリズムのすべての状態を渡すのは面倒になる可能性があるため、プライベートフィールドを使用します。また、基本的にインスタンスの状態であるため、最初の段落の規則とも一致しています。プライベートフィールドを使用する場合、アルゴリズムがリエントラントではないことを念頭に置いて適切に文書化するだけです。これはほとんどの場合問題ではありませんが、噛みつく可能性があります。

何かをする例を試してみましょう。これはjavaではなくjavascriptなので、許してください。ポイントは同じでなければなりません。

訪問https://blockly-games.appspot.com/pond-duck?lang=enを、JavaScriptのタブをクリックし、これを貼り付けます。

hunt = lock(-90,1), 
heading = -135;

while(true) {
  hunt()  
  heading += 2
  swim(heading,30)
}

function lock(direction, width) {
  var dir = direction
  var wid = width
  var dis = 10000

  //hunt
  return function() {
    //randomize() //Calling this here makes the state of dir meaningless
    scanLock()
    adjustWid()
    if (isSpotted()) {
      if (inRange()) {
        if (wid <= 4) {
          cannon(dir, dis)
        }
      }
    } else {
      if (!left()) {
        right()
      }
    }
  }

  function scanLock() {
    dis = scan(dir, wid);
  }

  function adjustWid() {
    if (inRange()) {
      if (wid > 1)
        wid /= 2;
    } else {
      if (wid < 16) {
        wid *= 2; 
      }
    }
  }

  function isSpotted() {
    return dis < 1000;
  }

  function left() {
    dir += wid;
    scanLock();
    return isSpotted();
  }

  function right() {
    dir -= wid*2;
    scanLock();
    return isSpotted()
  }

  function inRange() {
    return dis < 70;
  }

  function randomize() {
    dir = Math.random() * 360
  }
}

あなたはそれに気づくはずですdir、widとdisたくさんの周りに渡され取得されていません。また、lock()返す関数内のコードは擬似コードによく似ていることに注意してください。それは実際のコードです。しかし、それは非常に読みやすいです。パスと割り当てを追加することもできますが、擬似コードでは決して見られない混乱が追加されます。

これらの3つの変数は永続状態であるため、割り当てと受け渡しを行わなくてもよいと主張したい場合はdir、ループごとにランダムな値を割り当てる再設計を検討してください。今は永続的ではありませんか？

確かに、今ではdirスコープ内にドロップダウンできますが、受け渡しと設定で擬似コードを乱雑にすることなく強制することはできません。

そのため、状態は、パスやリターンではなく、副作用を使用するかどうかを決定する理由ではありません。副作用だけで、コードが読めなくなるわけでもありません。純粋に機能的なコードの利点は得られません。しかし、よくできて、良い名前で、彼らは実際に読むのに素晴らしいことができます。

それは彼らが悪夢のようなスパゲッティになれないということではありません。しかし、それでは何ができないのでしょうか？

幸せなカモ狩り。