7

Javaで条件を適用するための正しいアプローチについての提案が必要です。

ユーザーに表示される文字列変数の値を変更する必要がある100の条件があります。

条件の例：a<5 && (b>0 && c>8) && d>9 || x!=4

より多くの条件がありますが、変数は多かれ少なかれ同じです。

私は今これをやっています：

    if(condition1)
    else if(condition2)
    else if(condition3)
    ...

スイッチケースの代替案は、明らかにif-elseのie内にネストされています

if(condition1)
 switch(x)
  {
   case y:
     blah-blah
   }        
else if(condition2)
switch(x)
  {
   case y:
     blah-blah
   }  
else if(condition3)
...

しかし、私は、ポリモーフィックサポートを備えたこのためのインターフェイスを使用するような、より洗練されたソリューションを探しています。コード行を回避するために私ができることは何でしょうか、または正しいアプローチである必要があります。

- -編集 - -

ここに画像の説明を入力してください

私は実際にAndroidデバイスでこれを必要とします。しかし、ここではJava構造の詳細があります。

これは私が持っている状態の小さなスナップショットです。いくつかの合格/不合格の場合、さらに追加されます。それには明らかに、ネストの有無にかかわらず、より多くのif-elseが必要になります。その場合、処理が遅くなります。

現在、静的に保持しているさまざまな文字列変数を使用してメッセージを別のクラスに格納しているため、条件がtrueになると、唯一のクラスから静的変数を選択して表示します。結果のメッセージを保存することについては正しいでしょうか。

4

4 に答える 4

7

HashMap条件付き入力の数によっては、すべての入力または比較的単純な複雑な条件を1つの値にエンコードすることで、ルックアップテーブルまたはを使用できる場合があります。

int key = 0;

key |= a?(1):0;
key |= b?(1<<1):0;
key |= (c.size() > 1)?(1<<2):0;
...

String result = table[key]; // Or result = map.get(key);

このパラダイムには、一定の時間（O(1)）の複雑さという追加の利点があります。これは、場合によっては重要になることがあります。条件の複雑さによっては、本格的なif-then-elseスパゲッティコードとは対照的に、コードパスのブランチが平均して少なくなる場合があります。これにより、パフォーマンスが向上する可能性があります。

質問にコンテキストを追加していただければ、さらにサポートできる可能性があります。条件入力はどこから来ていますか？彼らはどんな人ですか？

そして、より重要な質問：あなたが解決しようとしている実際の問題は何ですか？

于 2013-01-09T13:52:39.450 に答える
4

これには多くの可能性があります。あなたのドメインについてあまり知らなくても、私は次のようなものを作成します（より良い名前を考えることができます：P）

 public interface UserFriendlyMessageBuilder {
      boolean meetCondition(FooObjectWithArguments args);

      String transform(String rawMessage);
 }

このようにして、Setのを作成し、UserFriendlyMessageBuilderそれらを繰り返し処理して、生のメッセージを変換するための条件を満たす最初のメッセージを作成できます。

public class MessageProcessor {
    private final Set<UserFriendlyMessageBuilder> messageBuilders;

    public MessageProcessor(Set<UserFriendlyMessageBuilder> messageBuilders) {
        this.messageBuilders = messageBuilders;
    }

    public String get(FooWithArguments args, String rawMsg) {

        for (UserFriendlyMessageBuilder msgBuilder : messageBuilders) {
            if (msgBuilder.meetCondition(args)) {
                return msgBuilder.transform(rawMsg);
            }
        }
        return rawMsg;    
    }
}
于 2013-01-09T13:53:55.690 に答える
0

私には、OOP言語を使用する主な要因である「モジュールで製品を設計することをあまり重要視していない」と思われます。

例：100の条件があり、4つのモジュールを作成できる場合は、回転的に選択するために26の条件が必要です。

于 2013-01-09T14:11:00.977 に答える
0

これは、検討する価値のある追加の可能性です。

それぞれの比較を行い、その真理値を計算してから、結果のブール値[]を真理値表で調べます。適用できる真理値表を単純化するための既存の作業はたくさんあります。私は何年も前に書いた真理値表の簡略化アプレットを持っています。あなたはそのソースコードが役に立つと思うかもしれません。

これのコストは、すべての比較、または少なくとも簡略化された真理値表を使用して式を評価するために必要な比較を行うことです。利点は、条件の複雑な組み合わせを管理するための組織化されたシステムです。

コードで真理値表を直接使用しない場合でも、コードを整理する方法として、真理値表を記述して単純化することを検討してください。

于 2013-01-09T14:41:34.237 に答える