2016-09-02 10 views
0

次の方法はコードの設計が間違っていますか?危険なコードを保護するためのブール型パラメータの追加

public void aMethodThatDoesHorribleIrreversibleDamageIfTheUserIsntCareful(boolean doAction) { 
    if (!doAction) 
     return; 

    //rest of dangerous and irreversible method code 
} 

このメソッドは、(適切に名前が付けられているように)元に戻すことができない危険な動作を行います。

このメソッドを呼び出すときに、より注意を払うように強制するには、ブール値フラグをパラメータとして使用するのが悪い習慣ですか?

このパラメータを使用するメリットは、発信者が危険で変更不可能な操作を実行したことをユーザーに警告し、実行することを確認するメッセージを表示することです。

このようなメソッドパラメータは、目的を果たすか、時間の無駄です(さらにメソッドパラメータリストを乱雑にする)かどうかを確認することができます。

+0

より良いオプションは、発信者がユーザーに警告して確認を求めてから、プロンプトに* No *と書かれていれば、最初は決して破壊的機能を呼び出さないことです。フラグは必要ありません。 –

+0

あなたの呼び出し元は、呼び出された他の場所から 'whateverHorribleFunction(true)'をコピーするだけです。その引数の名前が何であるか、何をしているのか分からずにコピーします。 – user2357112

答えて

2

これは、多くのレベルで間違っている:

  1. あなたは、この方法はとても恐ろしいと思われる場合は、なぜあなたが最初の場所であなたのソースコードに入れていませんでした!
  2. すでに誰かがこのようなメソッドが存在し、呼び出すことができると考えた場合は、ブール値の引数を追加すると、誰かがメソッドを呼び出すのを防ぐことができると本当に思いますか?
  3. これに対して、「可読性」または「ユーザーエクスペリエンス」という観点からは、絶対に価値のないパラメータを追加することになります。誰もがその方法を真実で呼ぶだけです。あなたが達成する唯一のことは、人々が提供する議論についてさらに考えなくても、あなたのメソッドを呼び出すように訓練を受けることです。
  4. 適切なインターフェイスを使用すると、適切な処理が簡単に行えます。間違ったことをするのは難しいです。

最後のポイントはここのみ許容の答えにつながる:メソッド実ユーザ後(あなたのアプリケーションを実行している人)が警告して、「はい、はい、ことが確認されていることをのみコールはい、それを行う "と言いました。そして、コーディングの観点から、あなたは良い命名でそれを達成します...

つまり、あなたの同僚とエンドユーザーを区別する必要があります。とにかく、あなたの同僚はソースコードに完全にアクセスできます。ブール値を増やしても、間違ったことをすることはありません。彼らが間違ったことをするのを防ぐのは、読みやすく理解しやすいコードと「チームポリシー」と「アプリケーション設計」に関する教育です。

すべての開発者がこの方法について理解している場合は、それが何をしているのか、彼らは注意するよりも。

他のグループ、あなたのエンドユーザー:と言ったように - 彼らは "恐ろしい"あなたは彼らに警告しましたが、彼らは今でもそうしたいと思います。

関連する問題