2

シナリオ: なんらかの方法で微調整する必要がある関数があります (例: 場所によって動作が若干異なるようにする)。何らかの理由で、関数または既存の呼び出しサイトのいずれかで、コードに醜いものを追加する必要があります。「醜い」の合計はどちらの場合も同じであると仮定します。

問題は、どの選択肢を選ぶべきか、そしてその理由です。

それを見る必要がないようにカプセル化する必要がありますか、それとも関数にセマンティックなゴミを追加しないように抽出する必要がありますか?

あなたの選択に何が影響しますか？次の場合はどうでしょうか。

  • この関数は、現在の場所以外から呼び出されることはありません。
  • 関数への新しい呼び出しには、「醜さ」は必要ありません。
  • 関数は今のところ本当にきれいで一般的です
  • 関数はすでにハックジョブです。
  • あなたは関数を書きました
  • あなたは関数を書きませんでした
  • 等
4

5 に答える 5

5

醜いものを関数に入れて、手を下ろします。これがC++の場合は、必ず.cppファイルに実装してください。おそらく、メインの関数本体から醜いものを抽象化するために2つの関数を書くことを検討するかもしれません。

手続き型/OOPプログラミングは、（とりわけ）インターフェースから「醜い」ものを取り除くために存在します。関数を呼び出すために必要なコードが多いほど、関数の有用性が低下することを理解することが重要です。また、コードを明確に文書化することを忘れないでください。そこには醜いコードがあり、その理由に注意してください。

また、この関数が十分に大きい場合は、独自の.csファイルまたは.cpp / .hペア（使用している言語に応じて）に入れることを検討してください。

于 2008-10-16T00:18:40.767 に答える
3

新しい発信者が醜さを必要としない場合は、醜さを新しい関数/ヘルパー/その他にカプセル化し、古い呼び出し元から呼び出して、新しい呼び出し元の既存の関数を汚染しないようにします。古い発信者間で複製されます。

新しい呼び出し元に必要になることがない場合は、機能を適切にテストできる限り、本質的にレガシーコンポーネントであるため、関数に追加します（関数のコンテキストで意味がある場合）。

結論として、複数の呼び出し元に重複がないことと、新しいコードへの露出を最小限に抑えることの両方で、醜さを最小限に抑えるようにしています。ユニットテストできるところまでカプセル化します。

誰が書いたのかは私の決定には影響しません。

于 2008-10-16T00:20:28.017 に答える
0

私はそれを関数宣言に個人的に入れます-関数の呼び出しにそれを入れることが「醜くない」ことを理解することはできません。 「醜い」を2回以上。

于 2008-10-16T00:22:00.043 に答える
0

醜いものをラッパー関数にカプセル化し、ラッパーを使用するために醜いものを必要とするすべての関数を変更します。

//old call
call_some_function_with_ugly(params, case)

// new call
call_some_function(params)

void call_some_function(params){ }

void call_some_function_with_ugly(params, case){
    // do ugly depending on case
    switch(case) { ... }

    call_some_function(params);
}
于 2008-10-16T02:30:39.050 に答える
0

機能に醜さを絶対に置きます。あなたができる最悪のことの 1 つは、コードの残りの部分全体に醜さを広めることです。醜さが予見できない方法で変化すると、これらを追跡することは不可能になります (醜さはたまたま起こります)。

もちろん、そもそも醜いものがないのが一番ですが……今、具体的にどんな例を思い浮かべますか？

于 2008-10-17T06:31:50.623 に答える