ブールパラメータを使用して動作を決定するのは間違っていますか？

私は時々「違和感を感じる」練習を見てきましたが、それについて何が悪いのかを明確に説明することはできません。または多分それはちょうど私の偏見です。ここに行く：

開発者は、パラメータの1つとしてブール値を使用してメソッドを定義し、そのメソッドは別のメソッドを呼び出すなど、最終的にそのブール値は、特定のアクションを実行するかどうかを決定するためだけに使用されます。これは、たとえば、ユーザーが特定の権限を持っている場合、またはテストモード、バッチモード、またはライブモードの場合（またはそうでない場合）にのみアクションを許可するために、またはシステムが特定の状態。

さて、それを行う別の方法が常にあります。（パラメータを渡すのではなく）アクションを実行するときを照会するか、メソッドの複数のバージョン、またはクラスの複数の実装などを使用します。私の質問はこれをどのように改善するかではなく、むしろそれが本当に間違っているかどうか（私が疑うように）、もしそうなら、何が悪いのか。

はい、これはおそらくコードの匂いであり、理解しにくく、簡単に再利用される可能性の低い保守不可能なコードにつながります。

他のポスターはコンテキストがすべてだと指摘しているように（1回限りの場合や、後でリファクタリングするために意図的に技術的負債が発生したとして慣行が認められている場合は、手に負えないでください）実行する特定の動作を選択する関数にするには、さらに段階的な改善が必要です。この関数をより小さな関数に分割すると、より凝集度の高い関数が生成されます。

それでは、高度に凝集した関数とは何ですか？

これは、1つのことと1つのことだけを行う機能です。

説明どおりに渡されるパラメーターの問題は、関数が2つ以上のことを実行していることです。ブール値パラメーターの状態に応じてユーザーのアクセス権をチェックする場合としない場合があり、その決定ツリーに応じて機能の一部を実行します。

アクセス制御の懸念をタスク、アクション、またはコマンドの懸念から分離する方がよいでしょう。

既に述べたように、これらの懸念は絡み合っていないようです。

したがって、凝集性の概念は、問題の関数が高度に凝集性ではなく、コードをリファクタリングして、より凝集性の高い関数のセットを生成できることを識別するのに役立ちます。

そのため、質問は修正できます。行動選択パラメーターを渡すことは、問題をどのように改善すればよいのでしょうか？

パラメータを完全に取り除きます。テスト中でもアクセス制御をオフにする機能を持つことは、潜在的なセキュリティリスクです。テスト目的で、アクセスチェックをスタブまたはモックして、許可されたアクセスシナリオとアクセスが拒否されたシナリオの両方をテストします。

参照：Cohesion（コンピューターサイエンス）

非常に簡単な理由で、私はずっと前にこのパターンの使用をやめました。メンテナンス費用。何度かfrobnicate(something, forwards_flag)、コード内で何度も呼び出される関数があり、値falseがの値として渡されたコード内のすべての場所を見つける必要があることを発見しましたforwards_flag。それらを簡単に検索することはできないため、これはメンテナンスの頭痛の種になります。また、これらの各サイトでバグ修正を行う必要がある場合、見逃した場合は不幸な問題になる可能性があります。

しかし、この特定の問題は、根本的にアプローチを変更することなく簡単に修正できます。

enum FrobnicationDirection {
  FrobnicateForwards,
  FrobnicateBackwards;
};

void frobnicate(Object what, FrobnicationDirection direction);

このコードでは、のインスタンスを検索するだけで済みますFrobnicateBackwards。これを変数に割り当てるコードがいくつかあるため、いくつかの制御スレッドに従う必要がありますが、実際には、これはこの代替が正常に機能するほどまれであることがわかります。

ただし、少なくとも原則として、この方法でフラグを渡すことには別の問題があります。これは、この設計を持つ一部の（一部のみ）システムが、コードの深くネストされた部分（フラグを使用）の実装の詳細に関する知識を外部レイヤー（どの値を渡すかを知る必要がある）に公開しすぎる可能性があることですこのフラグで）。Larry Constantineの用語を使用するために、この設計では、セッターとブールフラグのユーザーとの間に強すぎる結合が存在する場合があります。フランキーですが、コードベースについて詳しく知らなくても、この質問についてある程度の確信を持って言うことは困難です。

あなたが与える特定の例に対処するために、私はそれぞれにある程度の懸念を持っていますが、主にリスク/正確さの理由があります。つまり、システムがどの状態にあるかを示すフラグをシステムで渡す必要がある場合、これを考慮すべきであるがパラメーターをチェックしないコードがあることに気付くかもしれません（渡されなかったため）この関数）。だから、パラメータを渡すために誰かが省略したため、バグがあります。

また、ほぼすべての関数に渡す必要があるシステム状態インジケーターは、実際には本質的にグローバル変数であることを認める価値があります。グローバル変数の欠点の多くが適用されます。多くの場合、そのデータに基づいて正しく動作する責任があるオブジェクト内にシステム状態（またはユーザーの資格情報、またはシステムのID）の知識をカプセル化することをお勧めします。次に、生データではなく、そのオブジェクトへの参照を渡します。ここの主要な概念はカプセル化です。

これは必ずしも間違っているわけではありませんが、コードの匂いを表しています。

ブールパラメータに関して回避すべき基本的なシナリオは次のとおりです。

public void foo(boolean flag) {
    doThis();
    if (flag)
        doThat();
}

次に、電話をかけるとき、通常は電話をかけfoo(false)、foo(true)必要な正確な動作に依存します。

これは、結束が悪い場合であるため、本当に問題です。メソッド間に依存関係を作成していますが、これは実際には必要ありません。

この場合に行うべきことは、別のパブリックメソッドとしてそのままにdoThisしdoThatておきます。

doThis();
doThat();

または

doThis();

こうすることで、結合を作成せずに正しい決定を呼び出し元に任せます（ブール値のパラメーターを渡すように正確に）。

もちろん、すべてのブール値パラメーターがこのように悪い方法で使用されるわけではありませんが、間違いなくコードのにおいであり、ソースコードで多くを見れば疑わしくなります。

これは、私が書いた例に基づいてこの問題を解決する方法の一例です。別のアプローチが必要になる他のケースがあります。

同じ考えをさらに詳しく説明しているMartin Fowlerの良い記事があります。

PS：foo2つの単純なメソッドを呼び出す代わりにメソッドの実装がより複雑な場合は、小さなリファクタリング抽出メソッドを適用するだけで、結果のコードはfoo私が書いた実装に似たものになります。

まず、プログラミングは科学であり、芸術です。したがって、プログラムの「間違った」方法と「正しい」方法はほとんどありません。ほとんどのコーディング標準は、一部のプログラマが有用と考える「好み」にすぎません。しかし、最終的にはかなりarbitrary意的です。そのため、パラメーターの選択肢自体に「間違った」ラベルを付けることは決してありません。また、ブールパラメーターほど一般的で有用なものではありません。多くの場合、状態をカプセル化するためのa boolean（またはそのための）の使用intは完全に正当化されます。

コーディングの決定は、概して、主にパフォーマンスと保守性に基づいている必要があります。パフォーマンスが危険にさらされていない場合（そして、あなたの例でこれがどのようになり得るか想像できません）、あなたの次の考慮事項は次のとおりです。直感的でわかりやすいですか？孤立していますか？連鎖関数呼び出しのあなたの例は、実際にはこの点で潜在的に脆いようです：あなたは変更することを決定した場合bIsUpにはbIsDown、コード内の他の場所があまりにも変更する必要がありますどのように多くの？また、パラメーターリストはバルーニングしていますか？関数に17個のパラメーターがある場合、読みやすさが問題になるため、オブジェクト指向アーキテクチャーの利点を理解しているかどうかを再検討する必要があります。

Robert C Martins Cleanのコード記事では、メソッドが複数のことを行うことを示すため、可能であればブール引数を削除する必要があると述べていると思います。メソッドは1つのことを実行する必要があり、私が思うのは彼のモットーの1つだけです。

ここで最も重要なことは実用的であることだと思います。

ブール値が動作全体を決定する場合、2番目のメソッドを作成します。

ブール値が真ん中の少しの動作を決定するだけの場合、コードの重複を減らすためにブール値を1つにしたい場合があります。可能であれば、メソッドを3つに分割することもできます。ブールオプションの2つの呼び出しメソッドと、大部分の作業を行うメソッドです。

例えば：

private void FooInternal(bool flag)
{
  //do work
}

public void Foo1()
{
  FooInternal(true);
}

public void Foo2()
{
  FooInternal(false);
}

もちろん、実際には、これらの両極端の間には常にポイントがあります。通常、私は自分が正しいと思うことだけを行ないますが、コードの重複が少ないという点で誤りを好むのです。

不変のインスタンスを返すビルダーメソッドを使用して動作をカスタマイズするアプローチが好きです。GuavaでのSplitter使用方法は次のとおりです。

private static final Splitter MY_SPLITTER = Splitter.on(',')
       .trimResults()
       .omitEmptyStrings();

MY_SPLITTER.split("one,,,,  two,three");

これの利点は次のとおりです。

• 優れた可読性
• 設定方法とアクション方法の明確な分離
• オブジェクトが何であるか、何をすべきか、何をすべきでないかを考えさせることにより、結束を促進します。この場合、それはSplitterです。someVaguelyStringRelatedOperation(List<Entity> myEntities)という名前のクラスを配置することはありませんが、クラスSplitterの静的メソッドとして配置することを考えますStringUtils。
• インスタンスは事前に構成されているため、依存関係を簡単に注入できます。クライアントは、正しい振る舞いを得るためにメソッドを渡すtrueかfalseメソッドを心配する必要はありません。

間違いなくコードの匂い。単一責任原則に違反していない場合は、おそらく、「聞かないでください」に違反しています。考慮してください：

• あなたはあなたの方法が接続詞を使用せずに何をするかを要約できますか？
• 別の小さなメソッドに簡単にグループ化できるメソッドのサブパートはありますか？（これには、ローカル変数の複雑な作成が含まれます。）
• フラグがパラメーターで呼び出すメソッドを決定する場合、パラメーターが多すぎますか？
• このメソッドはパラメーターの1つに属しますか？（getters / settersを使用してパラメーター内のインスタンス変数を分離する場合は、気づくかもしれません。）

これらの2つの原則のいずれかに違反しないことが判明した場合でも、列挙型を使用する必要があります。ブールフラグは、マジックナンバーに相当するブールです。foo(false)と同じくらい理にかなっていbar(42)ます。列挙型は戦略パターンに役立ち、別の戦略を追加できる柔軟性があります。（それらに適切な名前を付けることを忘れないでください。）

あなたの特定の例は特に気になります。このフラグが多くのメソッドを通過するのはなぜですか？これは、パラメーターをサブクラスに分割する必要があるようです。

TL; DR：ブール引数を使用しないでください。

それらが悪い理由と、それらを交換する方法を以下に示します（太字）。

ブール引数は非常に読みにくいため、保守が困難です。主な問題は、引数に名前が付けられているメソッドシグネチャを読み取ると、目的が一般に明確になることです。ただし、ほとんどの言語では、通常、パラメーターに名前を付ける必要はありません。したがってRSACryptoServiceProvider#encrypt(Byte[], Boolean)、ブール型パラメーターが関数で使用される暗号化の種類を決定するようなアンチパターンがあります。

したがって、次のような呼び出しが行われます。

rsaProvider.encrypt(data, true);

読者は、単に地獄trueが実際に何を意味するかを判断するために、メソッドの署名を検索する必要があります。整数を渡すのはもちろん悪いことです。

rsaProvider.encrypt(data, 1);

同じくらい-またはむしろ：少しだけ教えてくれます。整数に使用する定数を定義した場合でも、関数のユーザーはそれらを単に無視してリテラル値を使用し続けることができます。

これを解決する最良の方法は、列挙を使用することです。RSAPadding2つの値を持つ列挙型を渡す必要がある場合：OAEPまたはPKCS1_V1_5、すぐにコードを読み取ることができます：

rsaProvider.encrypt(data, RSAPadding.OAEP);

ブール値には2つの値しか指定できません。つまり、3番目のオプションがある場合は、署名をリファクタリングする必要があります。一般に、後方互換性が問題になる場合、これは簡単に実行できないため、パブリッククラスを別のパブリックメソッドで拡張する必要があります。これはRSACryptoServiceProvider#encrypt(Byte[], RSAEncryptionPadding)、ブールの代わりに列挙（または、少なくとも列挙を模倣するクラス）を使用する場所を導入したときにMicrosoftが最終的に行ったことです。

パラメーター自体をパラメーター化する必要がある場合、パラメーターとして完全なオブジェクトまたはインターフェイスを使用する方が簡単な場合もあります。上記の例では、OAEPパディング自体をハッシュ値でパラメーター化して、内部で使用できます。現在、6つのSHA-2ハッシュアルゴリズムと4つのSHA-3ハッシュアルゴリズムがあるため、パラメーターではなく単一の列挙のみを使用すると、列挙値の数が爆発する可能性があることに注意してください）。

ブールパラメータは、メソッドまたはクラスが適切に設計されていないことを示す場合もあります。上記の例と同様に、.NET以外の暗号化ライブラリは、メソッドシグネチャでパディングフラグをまったく使用しません。

私が好きなほとんどすべてのソフトウェアの達人は、ブール引数に対して警告します。たとえば、Joshua Blochは高く評価されている「Effective Java」の本で彼らに警告しています。一般に、それらは単に使用されるべきではありません。理解しやすいパラメータが1つある場合に使用できると主張できます。しかし、その後も：Bit.set(boolean)おそらくより良い使用して実装された2つのメソッドを：Bit.set()とBit.unset()。

コードを直接リファクタリングできない場合、少なくとも定数を読みやすくするために定数を定義できます。

const boolean ENCRYPT = true;
const boolean DECRYPT = false;

...

cipher.init(key, ENCRYPT);

以下よりもはるかに読みやすい

cipher.init(key, true);

次のような場合でも：

cipher.initForEncryption(key);
cipher.initForDecryption(key);

代わりに。

誰もnamed-parametersに言及していないことに驚いています。

ブール値フラグで見られる問題は、それらが読みやすさを損なうことです。例えば、何んtrueで

myObject.UpdateTimestamps(true);

行う？何も思いつきません。しかし、どうですか：

myObject.UpdateTimestamps(saveChanges: true);

これで、渡しているパラメーターの意味が明確になりました。変更を保存するように関数に指示しています。この場合、クラスが非パブリックであれば、ブール値パラメーターは問題ないと思います。

もちろん、クラスのユーザーに名前付きパラメーターの使用を強制することはできません。このため、enumデフォルトのケースの頻度に応じて、通常、1つまたは2つの別々の方法が適しています。これがまさに.Netの機能です。

//Enum used
double a = Math.Round(b, MidpointRounding.AwayFromZero);

//Two separate methods used
IEnumerable<Stuff> ascendingList = c.OrderBy(o => o.Key);
IEnumerable<Stuff> descendingList = c.OrderByDescending(o => o.Key); 

私はそれについて何が悪いのかを明確に述べることはできません。

コードの匂いのように見え、コードの匂いのように感じ、そして-コードの匂いのような匂いがするなら、おそらくコードの匂いです。

あなたがしたいことは：

1）副作用のあるメソッドを避けます。

2）中央の正式なステートマシン（このような）で必要なステートを処理します。

私は、ブールパラメータを使用してパフォーマンスを決定しないためのすべての懸念に同意します。改善、可読性、信頼性、複雑さの低減、不十分なカプセル化と凝集によるリスクの低減、保守性による総所有コストの削減。

70年代半ばにハードウェアの設計を開始し、現在SCADA（監視制御およびデータ収集）と呼びます。これらは、マクロリモートコントロールを実行し、高速データを収集するEPROMのマシンコードを使用して微調整されたハードウェアです。

ロジックはMealey＆Moore マシンと呼ばれ、現在は有限状態マシンと呼ばれています。これらは、実行時間が有限のリアルタイムマシンである場合を除き、上記と同じルールで実行する必要があり、目的を果たすためにショートカットを実行する必要があります。

データは同期ですが、コマンドは非同期であり、コマンドロジックはメモリレスブールロジックに従いますが、前、現在、および望ましい次の状態のメモリに基づいたシーケンシャルコマンドを使用します。それが最も効率的な機械語（64kBのみ）で機能するように、ヒューリスティックなIBM HIPO方式ですべてのプロセスを定義するように細心の注意が払われました。それは、ブール変数を渡し、インデックス付きブランチを実行することを意味する場合がありました。

しかし、今では大量のメモリとOOKの容易さにより、カプセル化は今日の不可欠な要素ですが、コードがリアルタイムおよびSCADAマシンコードでバイト単位でカウントされた場合のペナルティです。

必ずしも間違っているわけではありませんが、「ユーザー」の属性に応じたアクションの具体例では、フラグではなくユーザーへの参照を渡します。

これは、いくつかの点で明確になり、役立ちます。

呼び出しステートメントを読んだ人はだれでも、結果はユーザーによって変わることがわかります。

最終的に呼び出される関数では、ユーザー属性にアクセスできるため、より複雑なビジネスルールを簡単に実装できます。

「チェーン」内の1つの関数/メソッドがユーザー属性に応じて異なる処理を行う場合、「チェーン」内の他のメソッドの一部にユーザー属性に対する同様の依存関係が導入される可能性が非常に高くなります。

ほとんどの場合、この悪いコーディングを検討します。ただし、2つのケースが考えられますが、これは良いプラクティスかもしれません。なぜそれが悪いのかという多くの答えが既にあるので、私はそれが良いかもしれないときに2回提供します：

1つは、シーケンス内の各呼び出しがそれ自体で意味をなすかどうかです。呼び出し元のコードが trueからfalseまたはfalseからtrueに変更される場合、または呼び出されるメソッドがブールパラメーターを渡すのではなく直接使用するように変更される場合に意味があります。このような10回の呼び出しが連続して発生する可能性は小さいですが、発生する可能性があり、実行された場合は、プログラミングの実践として適切です。

2番目のケースは、ブール値を処理していることを考えると、少しのストレッチです。ただし、プログラムに複数のスレッドまたはイベントがある場合、パラメーターを渡すことが、スレッド/イベント固有のデータを追跡する最も簡単な方法です。たとえば、プログラムは2つ以上のソケットから入力を取得できます。あるソケットで実行されるコードは警告メッセージを生成する必要があり、別のソケットで実行されるコードは生成しない場合があります。次に、非常に高いレベルで設定されたブール値が、警告メッセージが生成される可能性のある場所への多くのメソッド呼び出しを介して渡されるようにします。複数のスレッドまたはインターリーブされたイベントにはそれぞれ独自の値が必要となるため、データはどのような種類のグローバルにも保存できません（非常に困難な場合を除きます）。

確かに、後者の場合には私はおそらくその唯一のコンテンツブールたクラス/構造体を作成して渡したいということを周りの代わりに。警告メッセージの送信先など、他のフィールドがすぐに必要になることはほぼ間違いないでしょう。

コンテキストは重要です。このようなメソッドはiOSでかなり一般的です。よく使用される例の1つとして、UINavigationControllerはmethodを提供し-pushViewController:animated:、animatedパラメーターはBOOLです。メソッドはどちらの方法でも基本的に同じ機能を実行しますが、YESを渡すと、あるView Controllerから別のView Controllerへの遷移をアニメーション化し、NOを渡すとアニメーション化しません。これは完全に合理的です。アニメーションを使用するかどうかを判断できるように、このメソッドの代わりに2つのメソッドを提供する必要があるのはばかげているでしょう。

Objective-Cでは、この種のことを正当化する方が簡単な場合があります。Objective-Cでは、メソッドの命名構文により、CやJavaなどの言語で得られるよりも各パラメーターのコンテキストが多くなります。それにもかかわらず、単一のパラメータをとるメソッドは簡単にブール値をとることができ、それでも意味があると思います。

file.saveWithEncryption(false);    // is there any doubt about the meaning of 'false' here?