2013-01-09 46 views
8

我需要建議在Java應用條件是正確的做法。java:一長串條件,該怎麼辦?

我有基於在我必須改變將被顯示給用戶的字符串變量的值100次的條件。

的示例條件:a<5 && (b>0 && c>8) && d>9 || x!=4

多個條件存在,但變量是相同的更多或更少。

我現在這樣做的:

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

開關的情況下選擇將明顯地有嵌套的if-else的即

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

內,但是我正在尋找像使用一些更優雅的解決方案一個支持多態支持的接口,可以做些什麼來避免代碼行或什麼是正確的方法。

---編輯---


enter image description here

我actualy這需要在Android設備上。但是更多的是這裏的java構造。

這是我與我的條件小的快照。如果有幾個是正確的,將會添加更多。這顯然需要更多的if-else,並且這些也可以嵌套。在這種情況下,處理會變得緩慢。

我截至目前存儲在各種字符串變量一個單獨的類的消息,因此如果條件得到真正 那麼那些我一直保持靜止我選擇從只類的靜態變量和顯示 一。關於存儲結果消息是否正確?

+4

我不確定要避免代碼行。但爲了提高業績,將更頻繁的案例放在最前面? –

+1

恕我直言,這個問題更適合http://codereview.stackexchange.com/ –

+4

對你來說性能有多重要?因爲在靈活性和可讀性方面的一些更「優雅」的解決方案將比醜陋的樹更糟 - 如果if-elses – radai

回答

7

取決於條件輸入的數量,您可能能夠使用查表,甚至HashMap,通過編碼在一個單一的值全部投入,甚至一些相對簡單的複雜條件:

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麪條代碼,這可能會導致性能的改善。

,如果你增加了更多的背景下您的問題,我們也許能幫助你更多。條件輸入來自哪裏?他們像什麼?

而且更重要的問題:What is the actual problem that you are trying to solve?

+0

我會試試看。 – Prateek

+1

我認爲這將很難維持,因爲最後會出現一連串的陳述,其中一個陳述本身很複雜。由於這些條件用於用戶消息,因此它們可能經常發生更改。所以你會在你的代碼中創建一個維護熱點。 – SpaceTrucker

+0

@SpaceTrucker:我原則上同意,儘管這取決於代碼的實際佈局以及它的用途。很有可能一旦OP讓我們知道這到底是什麼,我們將找到一個更優雅的解決方案來解決高層任務,而不是試圖回答「如何編碼一個複雜的Java中的邏輯表?「 – thkala

4

有很多的可能性這一點。不知道你的域名了,我會創造像(你能想到更好的名稱:P)

public interface UserFriendlyMessageBuilder { 
     boolean meetCondition(FooObjectWithArguments args); 

     String transform(String rawMessage); 
} 

通過這種方式,你可以創建UserFriendlyMessageBuilder一個Set,只是遍歷它們爲滿足第一改變原始信息的條件。

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;  
    } 
} 
+0

這將有一個O(N)查找時間(N是這樣的分類器的數量),而不是一個if-else樹更低的複雜性(理想情況下樹log(N)) – radai

+2

@radai我明白你的觀點。 〜Log(N)只會在if/elses嵌套在另一個if/elses時發生。如果不是,他們也將是相同的O(N)。此外,我認爲對於這種簡單比較的情況,花費的時間會非常少。 –

+0

@RalfHoppen if-elses不是嵌套在我的案例中,但它可能是一個選擇問題。讓我們也標記它添加天氣的建議我去與嵌套與否 – Prateek

0

在我看來,什麼是「你給了非常少的重要性來設計產品模塊」 這是使用面嚮對象語言的主要因素。

例如:如果您有100個條件,並且您可以製作4個模塊,則有條件地選擇任何東西都需要26個條件。

0

這是一個額外的可能性,可能值得考慮。

進行每個比較,並計算其真值,然後在真值表中查看得到的布爾值[]。您可以申請的simplifying truth tables有很多現有的工作。我有一個很多年前寫過的真理表格簡化表applet。你可能會發現它的源代碼很有用。

這樣做的代價是進行所有比較,或者至少是使用簡化真值表評估表達式所需的成本。優點是管理複雜條件組合的有組織的系統。

即使您不直接在代碼中使用真值表,也應考慮編寫並簡化爲一種組織代碼的方法。