0

「全部」と言って極端になりたくない

ポリモーフィズムがswitch-caseに取って代わったら、美しいデザインが多くを取り除くという印象を持っていました。今日、私は別のトピックを読みました。これは、継承を使用してif-elseを削除します。

私の理解では、デザインとは通常、プログラムの概念に親しみを感じさせ、プログラムを簡単に変更/拡張できるようにすることを意味します。でも時々、「if-else」も便利だと感じました。

いくつかのガイドラインがあるので、時々OOの概念を好むべきですが、他のシナリオでは「if-else」だけを使用する必要があります

4

4 に答える 4

1

複雑なif-elseステートメントのリファクタリングとクラス階層に使用されるif-elseロジックを区別する必要があると思います。

if-elseブロックが常に必要になりますが、コードはそれでもエレガントにできます。しかし、すべてのコードと同様に、それは維持され、読み取り可能でなければなりません。

if-esleブロックは、クラス階層のチェックに使用するとエレガントではありません。例えば：

if(object.instanceof derivedClassA) {
    object.doMethod();
}
else if(object.instanceof derivedClassB) {
    ....
}
else if(object.instanceof baseClass) {
}
...

これは、継承やポリモーフィズムなどのOOP手法を使用して処理できます。ただし、コードを改善することを目的とした他の手法と同様に、OOPは悪用されて過剰に使用される可能性があります。私は常に、戦略設計パターンを使用して継承を使いすぎないようにしています。これにより、よりもHAS-A関係を優先することが促進されIS-Aます。

于 2012-05-14T07:01:13.107 に答える
0

この場合に適用される可能性のある1つの規則は、古き良き「三つのルール」です。

http://en.wikipedia.org/wiki/Rule_of_three_(computer_programming）

于 2012-05-14T03:47:11.720 に答える
0

これについては、いくつかの熱狂的でキッチュな意見があります：http ://www.antiifcampaign.com/を参照してください。

ポリモーフィズムのない言語はたくさんあり、言語がそれをサポートしていても、実行時のポリモーフィズムがパフォーマンス上の理由で正当化できないシナリオがたくさんあることに注意することが重要です。たとえば、N体問題は、それが機能するとしても、ポリモーフィズムを使用する場所になります。

私はSOアンチイフキャンペーンでこの主題が好きです

于 2012-05-14T03:53:16.500 に答える
0

if ...else..。

シーケンシャルコードを見ると最も読みやすいです。読者がロジックをたどることができないことが多いため、ネストまたはチェーンすると問題が発生します。

金曜日が早く帰宅する場合、水曜日がコーヒーを飲む場合、土曜日または日曜日が家にいる場合

ステートメントがさらに混乱する場合はネストされます。

これらの場合、スイッチタイプのステートメントはテーブルのように見えるため、より明確になります。これも、読者が複数の選択肢に適していると感じるスタイルです。

デイケースの切り替え水曜日：コーヒーケースを飲む金曜日：家に帰る早めのケース土曜日、日曜日：家にいる

事前にオプションを知っていると、それにアプローチするためのより良い方法があります。

def test（v）：if v =='a'：何かをするelif v =='b'：何か他のことをする

test（'a'）test（'b'）

非効率的で不明確です。別の名前のメソッドを使用するか、vが外部ソースからのものである場合は、辞書を使用することをお勧めします。

選択肢=a：何かをするb：何か他のことをする

choices ['a']？（）choices ['b']？（）

この最後の例は、sudoコードが少なく、コーヒースクリプトが多いです。？関数呼び出しの前とは、ディクショナリ参照が有効でない場合に呼び出しが行われないことを意味します。

アンディの返事を読んだばかりです。三つのルールはいたるところにあります-そして正当な理由があります。上で説明したように、情報が多すぎると混乱が生じます。私はブログで三つのルールについて話します-特に分解によるデザインについて話すとき。

于 2012-05-14T04:00:33.900 に答える