Anti-if目的：ヌルをチェックする方法は？

Question

私は最近、the anti-if campaignと、ifsを使わずにコードを書くOOP gurusの努力を聞いたことがありますが、代わりに多態性を使用しています。私はちょうどそれがうまくいかなければならない、私は、どのようにそれがいつも働くべきであることを意味する。

私はすでにポリモーフィズムを使用しています（キャンペーンについてはわかりませんでした）ので、私は "悪い"と "危険な" ifsと私のコード（Java/Swift/Objective-C）ほとんどの場合、私がどこで使うのかを確認するためには、次のようなケースが考えられます。

1. ヌル値のチェック。これは、私がこれまでにifを使った場合の最も一般的な状況です。値がnullの可能性がある場合は、正しい方法で値を管理する必要があります。それを使用するには、代わりにnullでないことを確認する必要があります。私は、多形性がif文なしでこれをどのように補うことができるかは分かりません。
2. 正しい値を確認してください。私はここで例を挙げます：私はログイン/サインアップアプリケーションを持っているとしましょう。ユーザーが実際にパスワードを書いたか、それとも5文字を超えているかを確認したい。 if/switchなしでどうすればできますか？繰り返しますが、タイプについてではなく値についてです。
3. （オプション）チェックエラー。右の値についてはポイント2と似ているためオプションです。ブロック/クロージャで値またはエラー（paramsとして渡される）が得られた場合、nullかどうかを確認できない場合はどうしたらエラーオブジェクトを処理できますか？

このキャンペーンについて詳しく知りたい場合は、その範囲で回答してください。私は、これが彼らの目的を理解し、彼らが言うことをいかに効果的に行うことができるかを尋ねています。

したがって、ifsを使用していないことは、これまでのところ賢明なアイデアではないかもしれませんが、OOPプログラムで効果的に実行できるかどうかを尋ねるだけです。

Answer 1

ifを完全に排除することはできませんが、最小化することができます。

null値のチェックに関しては、null値を返すメソッドは、代わりにNull Objectを返すことができます。実際の値を表さず、実際の値と同じ動作を実装するオブジェクトです。その呼び出し元はヌルであるかどうかをチェックするのではなく、Nullオブジェクトのメソッドを呼び出すことができます。メソッド内にまだifが存在する可能性がありますが、発信者には何もする必要はありません。

正しい値のチェックに関しては、オブジェクトが誤った属性でインスタンス化されるのを防ぐのが最善の方法です。オブジェクトのすべてのユーザーは、オブジェクトの属性を調べて使用する必要がないと確信できます。同様に、オブジェクトが有効または無効の属性を持つことができる場合、オブジェクトは、現在の属性値に対して正しいことをする上位レベルのメソッドを提供することによって、ユーザーからその属性を隠すことができます。ここでもオブジェクト内にはまだifが存在しますが、発信者には何もする必要はありません。

エラーチェックには、呼び出し側が確認するのを忘れる可能性のあるnullエラー値を返すよりも優れた方法がいくつかあります。 1つは例外を発生させています。もう1つは、結果またはエラーを保持できる型のオブジェクトを返すことで、JavaのOptionalまたはHaskellのMaybeのように、タイプセーフなif - 任意の結果を操作する方法を提供します。

注意また、そのcase文がちょうどif Sを連結している（実際には、私はswitchはなくif/else ifでキャンペーンのホーム・ページにコードを書かれていると思います）、および多型とcaseを交換するパターンもあります、例えば、the Strategy pattern。

Answer 2

例外を発生させる代わりに、nullを確認する場合は、ifを使用することをお勧めします。また、一般的なケースでは、nullのチェックは、初期化されていない変数の操作を防ぐのに役立ちます。

Answer 3

ifをNullに使用すると、例外は単純なifチェックよりも多くのメモリを浪費するため、例外を発生させるよりも優れています。

Answer 4

switchにSOLIDを使用します。他はこれから継承したと考えている。

Answer 5

これは大きな質問で、私が参加したすべてのOOブートキャンプで尋ねられるものです。まず、我々は、IFSの多くと理由コードを理解する必要がある「悪い」または「危険な」です：

• 彼らはそれが難しい従うこと/理解すること、コードのcyclomatic complexityを高めます。
• テストを書くのがより複雑になります。テスト中のメソッド内の各ブランチフローをテストすることが各条件でますます困難になり、テストのセットアップが面倒になります。彼らはあなたのコードは、彼らがあなたの方法がうまく

カプセル化されていない兆候かもしれない小さな十分方法

に分割されていない兆候かもしれない

しかし、覚えておくべき一つの重要な事があります - ifsは完全にコードから削除することはできません。しかし、多態性、小さな動作の抽出、そしてこれらの動作を適切なクラスにカプセル化するなどの手法を使用して、それらを抽象化することができます。

今、我々はIFSを避けなければならない理由のいくつかを知っている、のは、あなたの質問に取り組むみましょう：

null値のチェック

1. ：Null object patternはあなたのコード（FTW多型）からヌルチェックを排除するのに役立ちます。 nullを返す代わりに、期待されるオブジェクトのNullObject表現Special Caseを返します。このNullObjectは、実際のオブジェクトと同じインタフェースを持ち、nullポインタの例外がスローされることを心配することなくオブジェクトのメソッドのいずれかを安全に呼び出すことができます。

2. 値の正確性の確認：これを行うには多くの方法があります。たとえば、検証ごとに個別のValidationRuleクラスを作成し、そのオブジェクトを検証するときにそれらの呼び出しを連鎖させることができます。 ifはまだ残っていますが、個別のValidationRule実装に抽象化されています。アイデアのためにCommand patternとChain Of Responsibility patternを探します。