# より良いソフトウェアを設計し、If-Else を置き換える 5 つの方法。初心者から上級者への例

これだけは言っておきます: If-Else は通常、適切な選択ではありません。

これにより、設計が複雑になり、コードの可読性が低下し、リファクタリングが困難になる可能性があります。

しかし、If-Else が事実上のコード分岐ソリューションになったのは当然です。これは、意欲的な開発者全員に最初に教えられることです。残念ながら、多くの開発者は、より適切な分岐戦略に進むことはありません。

一部の人々の信条は、「If-Else はハンマー、すべては釘」です。

いつ、より適切な方法を使用するべきかを区別できないことは、ジュニアとジュニアを区別するものの1つです。

この恐ろしい慣習に終止符を打つためのヒントとパターンをいくつか紹介します。

例ごとに難易度は上がります。

1. まったく不要な Else ブロック

これはおそらく、若手開発者が犯す最大の罪の 1 つです。以下の例は、If-Else が素晴らしいと言われたときに何が起こるかを示す好例です。

このプロセスを簡素化するには、else` ブロックを削除するだけです。

よりプロフェッショナルに見えますよね?

他のブロックが実際にはまったく必要ないことがよくあります。このケースのように、何らかのアクションを実行し、特定の条件が満たされた場合にすぐに戻りたいとします。

2. 値の割り当て

提供された入力に基づいて変数に新しい値を割り当てる場合は、無意味な If-Else をやめてください (より読みやすい性的な方法です)。 。

単純なことですが、これは恐ろしいことです。まず、If-Else はここのスイッチで簡単に置き換えることができます。ただし、else を完全に削除することで、このコードをさらに簡素化できます。

else が使用されない場合、読みやすいきれいなコードが残ります。また、単一の return ステートメントではなく、高速リターンにスタイルを変更したことにも注意してください。正しい値がすでに見つかっている場合、値のテストを続行しても意味がありません。

3. 前提条件のチェック

通常、メソッドが無効な値を提供した場合、続行する方法がないことがわかります。実行には意味があります。

以前の DefineGender メソッドがあるとします。このメソッドでは、指定された入力値が常に 0 または 1 でなければなりません。

値の検証を行わずにこのメソッドを実行しても意味がありません。したがって、メソッドの実行を続行する前に、いくつかの前提条件を確認する必要があります。

ガード句の防御コーディング手法を適用すると、メソッドの入力値をチェックしてからメソッドの実行を続行します。

#この時点で、値が予想範囲内にある場合にのみメイン ロジックが実行されるようにします。

現在、IF も 3 項に置き換えられています。これは、デフォルトで最後に「unknown」を返す必要がなくなったためです。

4. If-Else を辞書に変換 - If-Else を完全に回避する

いくつかの条件に基づいて選択する操作を実行する必要があるとします。将来的にはさらに操作を追加する必要があります。

試行済みの If-Else を使用することを好む人もいるかもしれません。新しいアクションを追加する場合は、単に別のアクションを追加するだけです。非常にシンプルですが、このアプローチはメンテナンスの観点からは良い設計とは言えません。

将来的に新しい操作を追加する必要があることがわかっているので、If-Else を辞書にリファクタリングできます。

#可読性が大幅に向上し、コードがより簡単に推論できるようになりました。

辞書は説明のみを目的としてメソッド内に配置されていることに注意してください。別の場所から提供することもできます。

5. アプリケーションを拡張する - If-Else の使用を完全に避ける

これは、もう少し高度な例です。

If をオブジェクトに置き換えて完全に削除するタイミングさえ知ってください。

アプリケーションの特定の部分を拡張する必要があることがよくあります。若手開発者は、If-Else (つまり else-if) ステートメントを追加してこれを実行したくなるかもしれません。

この具体的な例を挙げてください。ここでは、Order インスタンスを文字列として表示する必要があります。まず、文字列表現は JSON とプレーン テキストの 2 つだけです。前述したように、他のものを簡単に置き換えることができるのであれば、この段階では If-Else を使用することは大したことではありません。

#アプリケーションのこの部分を拡張する必要があることを認識しているため、このアプローチは絶対に受け入れられません。

上記のコードは、「オープン/クローズ」原則に違反するだけでなく、読みにくく、保守性の問題を引き起こす可能性があります。

正しいアプローチは、SOLID 原則に従うものです。これは、動的なタイプ検出プロセス (この場合は、Strategy パターン) を実装することによって行われます。

この厄介なプロセスをリファクタリングするプロセスは次のとおりです。

· 共通インターフェイスを使用して、各ブランチを個別の戦略クラスに抽出します。

· 共通インターフェイスを実装するすべてのクラスを動的に検索します

·入力に基づいて実行する戦略を決定する

まず、汎用インターフェイス IOrderOutputStrategy を実装するアセンブリ内のすべての型を取得します。次に、ディクショナリを作成します。フォーマッタの displayName の名前は key、タイプは value です。

次に、ディクショナリからフォーマッタ タイプを選択し、ポリシー オブジェクトのインスタンス化を試みます。

最後に、ストラテジー オブジェクトの ConvertOrderToString を呼び出します。

以上が当社はどのようにしてプロジェクト内の 2,000 件の if-else を完全に排除したのでしょうか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。