Uncle BobのClean Code原則に準拠するためにif-else ifステートメントのチェーンを編集するにはどうすればよいですか？

ボブおじさんのきれいなコードの提案に従い、特にメソッドを短くするようにしています。

ただし、このロジックを短縮することはできません。

if (checkCondition()) {addAlert(1);}
else if (checkCondition2()) {addAlert(2);}
else if (checkCondition3()) {addAlert(3);}
else if (checkCondition4()) {addAlert(4);}

私はelseを削除することができないため、全体を小さなビットに分割し、「else if」の「else」を使用するとパフォーマンスが向上します本当です、私はそれらを避けたいです。

意味的に言えば、前の条件が満たされた場合に次の条件を評価することは、ビジネスの観点からは意味がありません。

編集：この質問は、if（if else）elseを処理するエレガントな方法の可能な重複として識別されました。

これは別の質問だと思います（これらの質問の回答を比較することでも確認できます）。

• 私の質問は、すぐに終わる最初の受け入れ条件をチェックしています。
• リンクされた質問は、何かをするためにすべての条件を受け入れようとしている。（この質問に対するこの回答でよく見られます：https : //softwareengineering.stackexchange.com/a/122625/96955）

理想的には、アラートコード/番号を独自のメソッドに取り込むためのロジックを抽出する必要があると思います。したがって、既存のコードは、

{
    addAlert(GetConditionCode());
}

GetConditionCode（）で条件をチェックするためのロジックをカプセル化します。おそらく、マジックナンバーよりもEnumを使用した方が良いでしょう。

private AlertCode GetConditionCode() {
    if (CheckCondition1()) return AlertCode.OnFire;
    if (CheckCondition2()) return AlertCode.PlagueOfBees;
    if (CheckCondition3()) return AlertCode.Godzilla;
    if (CheckCondition4()) return AlertCode.ZombieSharkNado;
    return AlertCode.None;
}

重要な測定は、絶対サイズではなくコードの複雑さです。アクションが実際に示したものほど複雑ではないように、異なる条件は実際には単一の関数呼び出しであると仮定すると、コードには何も問題はありません。それは既に可能な限り単純です。

さらに「単純化」しようとすると、実際に事態は複雑になります。

もちろん、他の人が示唆elseしたreturnようにキーワードをに置き換えることができますが、それはスタイルの問題であり、複雑さの変化ではありません。

余談：

私の一般的なアドバイスは、きれいなコードのルールについて決して宗教的ではないことです：インターネット上で見るコーディングアドバイスのほとんどは、適切なコンテキストで適用されれば良いですが、どこにでも同じアドバイスを徹底的に適用すると、IOCCC。秘Theは常に、人間がコードについて簡単に推論できるようなバランスをとることです。

大きすぎる方法を使用してください。小さすぎる機能を使用すると、ねじが締められます。三項表現を避けてください、そしてあなたはめちゃくちゃです。どこでも三項式を使用してください、あなたはめちゃくちゃです。1行の関数を呼び出す場所と、50行の関数を呼び出す場所があることを認識します（はい、存在します！）。以下のための呼び出しという場所があることを実感if()文、およびのためのその呼び出し場所があることを?:オペレータが。あなたの自由に使える完全な武器を使用し、あなたが見つけることができる最も適切なツールを常に使用するようにしてください。そして、このアドバイスについても宗教的にならないでください。

これは、特定のケースで、通常のif..elseよりも「良い」かどうかについて議論の余地があります。しかし、他の何かを試したい場合は、これが一般的な方法です。

条件をオブジェクトに入れ、それらのオブジェクトをリストに入れます

foreach(var condition in Conditions.OrderBy(i=>i.OrderToRunIn))
{
    if(condition.EvaluatesToTrue())
    {
        addAlert(condition.Alert);
        break;
    }
}

条件に応じて複数のアクションが必要な場合は、おかしな再帰を実行できます

void RunConditionalAction(ConditionalActionSet conditions)
{
    foreach(var condition in conditions.OrderBy(i=>i.OrderToRunIn))
    {
        if(condition.EvaluatesToTrue())
        {
            RunConditionalAction(condition);
            break;
        }
    }
}

明らかにそうです。これは、ロジックにパターンがある場合にのみ機能します。超汎用の再帰的条件付きアクションを作成しようとすると、オブジェクトのセットアップは元のifステートメントと同じくらい複雑になります。独自の新しい言語/フレームワークを発明します。

しかし、あなたの例にはパターンがあります

このパターンの一般的な使用例は、検証です。の代わりに ：

bool IsValid()
{
    if(condition1 == false)
    {
        throw new ValidationException("condition1 is wrong!");
    }
    elseif(condition2 == false)
    {
    ....

}

になる

[MustHaveCondition1]
[MustHaveCondition2]
public myObject()
{
    [MustMatchRegExCondition("xyz")]
    public string myProperty {get;set;}
    public bool IsValid()
    {
        conditions = getConditionsFromReflection()
        //loop through conditions
    }
}

return;1つの条件が成功した後に使用することを検討してくださいelse。return addAlert(1)そのメソッドに戻り値がある場合は、直接できる場合もあります。

私は時々、このような構造がクリーナーと見なされるのを見てきました：

switch(true) {
    case cond1(): 
        statement1; break;
    case cond2():
        statement2; break;
    case cond3():
        statement3; break;
    // .. etc
}

正しい間隔の3進法も適切な選択肢です。

cond1() ? statement1 :
cond2() ? statement2 :
cond3() ? statement3 : (null);

条件と関数を含むペアで配列を作成し、最初の条件が満たされるまで繰り返し処理を試みることもできると思います。

@Ewanの回答の変形として、次のような条件のチェーン（「フラットリスト」の代わりに）を作成できます。

abstract class Condition {
  private static final  Condition LAST = new Condition(){
     public void alertOrPropagate(DisplayInterface display){
        // do nothing;
     }
  }
  private Condition next = Last;

  public Condition setNext(Condition next){
    this.next = next;
    return this; // fluent API
  }

  public void alertOrPropagate(DisplayInterface display){
     if(isConditionMeet()){
         display.alert(getMessage());
     } else {
       next.alertOrPropagate(display);
     }
  }
  protected abstract boolean isConditionMeet();
  protected abstract String getMessage();  
}

この方法では、定義された順序で条件を適用でき、インフラストラクチャ（示されている抽象クラス）は、最初のチェックが満たされた後、残りのチェックをスキップします。

これは、条件を適用するループで「スキップ」を実装する必要がある「フラットリスト」アプローチよりも優れている場所です。

条件チェーンを設定するだけです：

Condition c1 = new Condition1().setNext(
  new Condition2().setNext(
   new Condition3()
 )
);

そして、簡単な呼び出しで評価を開始します。

c1.alertOrPropagate(display);

まず、元のコードはひどいIMOではありません。それはかなり理解可能であり、本質的に悪いことは何もありません。

それからあなたがそれを嫌うなら、リストを使うが彼のやや不自然なforeach breakパターンを取り除くという@Ewanのアイデアに基づいて：

public class conditions
{
    private List<Condition> cList;
    private int position;

    public Condition Head
    {
        get { return cList[position];}
    }

    public bool Next()
    {
        return (position++ < cList.Count);
    }
}


while not conditions.head.check() {
  conditions.next()
}
conditions.head.alert()

選択した言語でこれを調整し、リストの各要素をオブジェクト、タプル、その他のものにします。

編集：私が思ったほど明確ではないように見えるので、さらに説明させてください。conditionsある種の順序付きリストです。head調査対象の現在の要素です。最初はリストの最初の要素であり、next()呼び出されるたびに次の要素になります。check()そして、OPからalert()のcheckConditionX()and addAlert(X)です。

質問にはいくつかの詳細が欠けています。条件が次の場合：

• 変更または
• アプリケーションまたはシステムの他の部分で繰り返される、または
• 特定の場合に変更（異なるビルド、テスト、展開など）

またはのコンテンツaddAlertがより複雑な場合、たとえばc＃のより良い解決策は次のようになります。

//in some central spot
IEnumerable<Tuple<Func<bool>, int>> Conditions = new ... {
  Tuple.Create(CheckCondition1, 1),
  Tuple.Create(CheckCondition2, 2),
  ...
}

//at the original place
var matchingCondition = Conditions.Where(c=>c.Item1()).FirstOrDefault();
if(matchingCondition != null) 
  addAlert(matchingCondition.Item2)

タプルはc＃<8ではそれほど美しくありませんが、利便性のために選択されています。

この方法の長所は、上記のオプションが適用されない場合でも、構造体が静的に型付けされることです。たとえば、を紛失して誤って台無しにすることはできませんelse。

たくさんある場合にCyclomaticの複雑さを軽減する最良の方法if->then statementsは、辞書またはリスト（言語依存）を使用してキー値（ステートメント値またはその値の場合）と値/関数の結果を保存することです。

たとえば、（C＃）の代わりに：

if (i > 10) { return "Two"; }
else if (i > 8) { return "Four" }
else if (i > 4) { return "Eight" }
return "Ten";  //etc etc say anything after 3 or 4 values

簡単にできる

var results = new Dictionary<int, string>
{
  { 10, "Two" },
  { 8, "Four"},
  { 4, "Eight"},
  { 0, "Ten"},
}

foreach(var key in results.Keys)
{
  if (i > results[key]) return results.Values[key];
}

より新しい言語を使用している場合は、より多くのロジックを格納でき、単純に値も格納できます（c＃）。これは実際には単なるインライン関数ですが、ロジックがインラインに配置するのが面倒な場合は、他の関数を指すこともできます。

var results = new Dictionary<Func<int, bool>, Func<int, string>>
{
  { (i) => return i > 10; ,
    (i) => return i.ToString() },
  // etc
};

foreach(var key in results.Keys)
{ 
  if (key(i)) return results.Values[key](i);
}

ボブおじさんのきれいなコードの提案に従い、特にメソッドを短くするようにしています。

ただし、このロジックを短縮することはできません。

if (checkCondition()) {addAlert(1);}
else if (checkCondition2()) {addAlert(2);}
else if (checkCondition3()) {addAlert(3);}
else if (checkCondition4()) {addAlert(4);}

コードはすでに短すぎますが、ロジック自体は変更しないでください。一見するとcheckCondition()、の呼び出しが4回繰り返されているように見えますが、コードを注意深く読み直した後はそれぞれが異なることが明らかです。適切なフォーマットと関数名を追加する必要があります。例：

if (is_an_apple()) {
  addAlert(1);
}
else if (is_a_banana()) {
  addAlert(2);
}
else if (is_a_cat()) {
  addAlert(3);
}
else if (is_a_dog()) {
  addAlert(4);
}

あなたのコードは何よりも読みやすいものでなければなりません。ボブおじさんの本を何冊か読んだことがあるが、それは彼が一貫して伝えようとしているメッセージだと思う。

すべての機能が同じコンポーネントに実装されていると仮定すると、フロー内の複数のブランチを取り除くために、機能に何らかの状態を保持させることができます。

EG：前の条件が満たされたかどうかをチェックcheckCondition1()するになりevaluateCondition1()ます。もしそうなら、それによって取得されるいくつかの値をキャッシュしますgetConditionNumber()。

checkCondition2()になりevaluateCondition2()、前の条件が満たされているかどうかを確認します。前の条件が満たされなかった場合、条件シナリオ2をチェックし、取得する値をキャッシュしますgetConditionNumber()。等々。

clearConditions();
evaluateCondition1();
evaluateCondition2();
evaluateCondition3();
evaluateCondition4();
if (anyCondition()) { addAlert(getConditionNumber()); }

編集：

このアプローチが機能するために、高価な条件のチェックを実装する必要がある方法を次に示します。

bool evaluateCondition34() {
    if (!anyCondition() && A && B && C) {
        conditionNumber = 5693;
        return true;
    }
    return false;
}

...

bool evaluateCondition76() {
    if (!anyCondition() && !B && C && D) {
        conditionNumber = 7658;
        return true;
    }
    return false;
}

したがって、実行する高価なチェックが多すぎて、このコードの内容がプライベートのままである場合、このアプローチはそれを維持するのに役立ち、必要に応じてチェックの順序を変更できます。

clearConditions();
evaluateCondition10();
evaluateCondition9();
evaluateCondition8();
evaluateCondition7();
...
evaluateCondition34();
...
evaluateCondition76();

if (anyCondition()) { addAlert(getConditionNumber()); }

この回答は、他の回答からいくつかの代替提案を提供するだけであり、おそらく4行のコードのみを考慮した場合、元のコードよりも良くなることはありません。私が言及したシナリオを考えると、これはひどいアプローチではありません（また、他の人が言ったようにメンテナンスを難しくすることもありません）

「else」句が2つを超えると、コードの読者はチェーン全体を調べて目的のコードを見つけます。次のようなメソッドを使用します。void AlertUponCondition（Condition condition）{switch（condition）{case Condition.Con1：... break; case Condition.Con2：... break; など...}「条件」は適切な列挙型です。必要に応じて、ブールまたは値を返します。次のように呼び出します：AlertOnCondition（GetCondition（））;

それは本当に簡単なものではありませんし、いくつかのケースを超えるとif-elseチェーンよりも高速になります。

コードが具体的ではないため、特定の状況について話すことはできませんが、...

そのようなコードは、多くの場合、オブジェクト指向モデルが欠けているためにおいです。本当に4つのタイプがあり、それぞれが独自のアラータタイプに関連付けられていますが、これらのエンティティを認識してそれぞれのクラスインスタンスを作成するのではなく、それらを1つのものとして扱い、後でそれを補おうとします。先に進むには何を扱っているかを知る必要があります。

多態性がより適している可能性があります。

長いまたは複雑なif-thenコンストラクトを含む長いメソッドを使用したコードには疑いを持ちます。多くの場合、いくつかの仮想メソッドを備えたクラスツリーが必要です。