受信パラメータの変更はアンチパターンですか？[閉まっている]

私はJavaでプログラミングしており、常にコンバーターを次のように作成しています。

public OtherObject MyObject2OtherObject(MyObject mo){
    ... Do the conversion
    return otherObject;
}

新しい職場でのパターンは次のとおりです。

public void MyObject2OtherObject(MyObject mo, OtherObject oo){
    ... Do the conversion
}

私にとっては、着信パラメータを変更しないことに慣れていたので、少し臭いです。この着信パラメータの変更はアンチパターンですか、それとも大丈夫ですか？重大な欠点がありますか？

これはアンチパターンではなく、悪い習慣です。

アンチパターンと単なる悪い習慣の違いは、アンチパターン定義です。

ボブおじさんのクリーンコードによると、あなたが示す新しい職場スタイルは悪い習慣であり、痕跡的またはOOP前の時代です。

引数は、関数への入力として最も自然に解釈されます。

関数のシグネチャを確認することを強制するものはすべて、ダブルテイクと同等です。それは認知の中断であり、避けるべきです。オブジェクト指向プログラミングの数日前には、出力引数が必要な場合がありました。ただし、出力引数の必要性の多くはオブジェクト指向言語ではなくなります

ロバートC.マーティンの有名な本「Clean Code」を引用：

出力引数は避けるべきです

関数には少数の引数が必要です

2番目のパターンは両方のルール、特に「出力引数」ルールに違反しています。この意味では、最初のパターンよりも悪いです。

呼び出し元は、繰り返しごとに新しいインスタンスを作成する代わりに、1つの変数を長いループで再利用できるため、2番目のイディオムは高速になります。

私は一般的にそれを使用しませんが、例えば。ゲームプログラミングでは、その場所があります。たとえば、JavaMonkeyのVector3fの多くの操作では、変更して結果として返す必要があるインスタンスを渡すことができます。

これらは2つの同等のコードだとは思いません。最初のケースでは、を作成する必要がありますotherObject。2番目の既存のインスタンスを変更できます。両方とも用途があります。コードの匂いは、他のものよりも好むでしょう。

本当に言語に依存します。

Javaでは、2番目の形式はアンチパターンである場合がありますが、一部の言語ではパラメーターの受け渡しが異なります。値または参照によって、例えば、代わりにパスのエイダとVHDLで、パラメータは、モードを有することができin、outまたはin out。

変更すると、エラーが発生しinたパラメータを読み込むか、outパラメータを、しかしへの変更in outパラメータは、呼び出し元に渡されます。

したがって、Adaの2つの形式（これらは合法的なVHDLでもあります）は

function MyObject2OtherObject(mo : in MyObject) return OtherObject is
begin
    ... Do the conversion
    return otherObject;
end MyObject2OtherObject;

そして

procedure MyObject2OtherObject(mo : in MyObject; oo : out OtherObject) is
begin
    ... Do the conversion
    oo := ... the conversion result;
end MyObject2OtherObject;

どちらにも用途があります。プロシージャは複数のOutパラメータで複数の値を返すことができますが、関数は単一の結果のみを返すことができます。2番目のパラメーターの目的はプロシージャ宣言で明確に記述されているため、このフォームに異議はありません。私は読みやすさのために機能を好む傾向があります。ただし、呼び出し元がオブジェクトをすでに作成している場合など、プロシージャの方が優れている場合があります。

それは確かに臭いのように見えます、そして、より多くの文脈を見ないで、それは確かに言うことは不可能です。これを行うには2つの理由がありますが、両方の選択肢があります。

まず、それは部分的な変換を実装するか、変換が失敗した場合に結果をデフォルト値のままにする簡潔な方法です。つまり、これがあるかもしれません：

public void ConvertFoo(Foo from, Foo to) {
    if (can't convert) {
        return;
    }
    ...
}

Foo a;
Foo b = DefaultFoo();
ConvertFoo(a, b);
// If conversion fails, b is unchanged

もちろん、通常、これは例外を使用して処理されます。ただし、何らかの理由で例外を回避する必要がある場合でも、これを行うためのより良い方法があります-TryParseパターンは1つのオプションです。

別の理由は、純粋な一貫性の理由である可能性があることです。たとえば、何らかの理由でこのメソッドがすべての変換関数（複数の出力を持つ他の変換関数など）に使用されるパブリックAPIの一部です。

Javaは複数の出力を処理するのが得意ではありません。一部の言語のような出力専用のパラメーターや、他の言語のような複数の戻り値を持つことはできませんが、それでも戻りオブジェクトを使用できます。

一貫性の理由はかなり不十分ですが、悲しいことに最も一般的かもしれません。

• おそらく、職場（またはコードベース）のスタイル警官はJava以外のバックグラウンドから来たものであり、変更に消極的でした。
• あなたのコードは、このスタイルがより慣用的な言語からの移植であったかもしれません。
• 組織は異なる言語間でAPIの一貫性を維持する必要がある場合があり、これは最も一般的な分母のスタイルでした（それは簡単ですが、Googleでも起こります）。
• または、遠い過去にスタイルがより意味を持ち、現在の形式に変形した可能性があります（たとえば、TryParseパターンである可能性がありますが、一部の善意の前身は、誰もそれをまったくチェックしなかったことを発見した後、戻り値を削除しました）。

2番目のパターンの利点は、呼び出し元に作成されたオブジェクトの所有権と責任を強制させることです。メソッドがオブジェクトを作成したか、再利用可能なプールから取得したかは疑いありません。呼び出し側は、新しいオブジェクトの寿命と廃棄に責任があることを知っています。

この方法の欠点は次のとおりです。

1. ファクトリメソッドとして使用することはできません。呼び出し元はOtherObject、必要なサブタイプを正確に把握し、事前に構築する必要があります。
2. これらのパラメーターが由来する場合、コンストラクター内のパラメーターを必要とするオブジェクトでは使用できませんMyObject。OtherObjectについて知らなくても構築可能でなければなりませんMyObject。

答えは、c＃での私の経験に基づいています。ロジックがJavaに変換されることを望みます。

緩い意味論を考える- myObjectToOtherObject均等にあなたが移動することを意味するかもしれないいくつかの秒に最初のオブジェクトからデータをかあなたは完全に新たにそれを変換することを、第二の方法は、より適切なようです。

ただし、メソッド名がConvert（「...変換を行う」部分を見ればわかるはずです）、2番目のメソッドは意味をなさないと思います。値を既存の別の値、IMOに変換しません。