web-dev-qa-db-ja.com

フィールドとメソッド引数

私は新しいクラスを書き始めたばかりで、厳密には必要のないメソッド引数をたくさん追加していることに気付きました。これは、クラスの一般的な構成や依存関係ではなく、特定のメソッド呼び出しに固有の状態をクラス内に持たないようにする習慣に従っています。

そうすることは、引数を持たない可能性のある多くのメソッドが1、2、または3で終わることを意味します。

このトレードオフについてどう思うか、どのような状況でどのアプローチを取るかをどのように決定するかについて、あなたの意見を聞きたいのですが。

コードを記述する場合、コードは英語よりも理解しやすいことが多いため、両方のバリアントを含む小さなGistを作成しました: https://Gist.github.com/JeroenDeDauw/6525656

9
Jeroen De Dauw

あなたの例の外部から見える唯一のメソッドはupdateTableであるため、メソッドパラメータの代わりにフィールドを使用しても問題ないと思います。

これがより一般的なクラス(たとえばTableTools)の一部である場合、状態を必要とするヘルパーメソッドを非表示の内部クラスに移動します。

疑似コードの例:

class TableTools {
    ...
    public void updateTable(currentTable, newTable) {
        TableUpdater u = new TableUpdater(schemaModifier, currentTable, newTable);
        u.removeRemovedFields();
        u.addAddedFields();
     }

     private class TableUpdater { ... }
}

これにより、1つのパブリックメソッドのみで使用されるフィールドを回避できます。さらに、コードは、updateTableへのすべての呼び出しがTableUpdater、つまりTableUpdaterのインスタンス変数の独自のコピーを使用するという意味でスレッドセーフです。

2
Heinzi

フィールドを使用すると、それらのフィールドを使用するメソッドでマルチスレッドを使用できるようになります。

このようなフィールドを使用することは、再利用性と保守性の観点からグローバルを使用するよりもわずかに優れています。ここで重要な点は、複雑なセットアップでは、どのメソッドを使用するか、どのフィールドを使用するかについて、慎重かつ最新のドキュメントが必要であることです。引数を使用するときに必要のないもの。

7
ratchet freak

素人の言葉で:

  • メソッドは引数をできるだけ少なくする必要があります(MartinのClean Code)
  • オブジェクトの機能の1つは、状態を持つことができる(そして持つべきである)ものです。
  • オブジェクトの状態を操作しない、つまりすべてをパラメーターとして受け取る非静的メソッドは、まとまりがありません
  • 非まとまりのないメソッドを静的にして、ユーティリティクラスにグループ化することもできます。

繰り返しになりますが、私の考えでは、まとまりのないメソッドは、ドメイン名を持つクラスではなく、ユーティリティクラスに属しています。

7

現在のケースではフィールドを使用しないでください!オブジェクトを同時に使用する2つの「スレッド」は、互いに深刻な混乱を招きます。それらは、実際の別々のスレッドである必要もありません(したがって引用符)。オブジェクトを1つのテーブルに設定し、それを別のテーブルに使用するメソッドを呼び出してから、元の設定を使用しようとすると、問題が発生します。とりあえずパラメータを使いましょう。

What youwantto here hereは、1つのケースでのみ使用される新しいアップデータクラスを作成します。元のクラスには、必要に応じてインスタンスを作成するメソッドを含めることができます。新しいクラスにはフィールドがあります。あなたは両方の長所を持っています。場合によっては、パラメータを使用する方が簡単な場合もありますが、この例では、別のクラスの方が優れている場所にすでに到達しています。

1
RalphChapin

あなたがそれを見るように、私は、選択は実際の状況に従っているべきだと思います。アイテムがインスタンスに属している場合は、そのフィールドと見なされます。アイテムがインスタンスの外部にある場合は、メソッドパラメータとして渡す必要があります。

この場合、有効性(違いはとにかく取るに足らない)や(神の救い!)入力のしやすさではなく、コードの理解可能性と自然さによって導かれるべきです。

0
Gangnus

私の意見では、何かに何かをするコードを書いている場合それはそれが何をすべきかを定義するパラメータを取り、その名前はできる限り定義するべきですそれに。

何かに対して実行されるアクションをパッケージ化するコードを記述している場合は、で実行する必要のあるものをオブジェクトにラップし、それをオブジェクトに渡します何かをする

この action は、最初のメソッドの呼び出しの一種のメタ記述になり、後でキューに入れたり、実行しないことを決定したりすることができます。なんらかの理由でそれはまったくありません。

したがって、あなたの質問はis an Action またはa Function Action は延期またはキャンセルされる可能性があるため、それが作用する対象をカプセル化する必要があります。 Function はすぐに実行されるため、パラメーターを保持する必要はありません。

undoおよび Action はできますが、 Function はできません。

0
OldCurmudgeon