Java: Długa lista warunków, co robić?

Question

Potrzebuję sugestii co do właściwego podejścia do stosowania warunków w Javie.

Mam 100 warunków, na podstawie których muszę zmienić wartość zmiennej String, która byłaby wyświetlana użytkownikowi.

przykład warunek: a<5 && (b>0 && c>8) && d>9 || x!=4

Więcej warunki są tam, ale zmienne są takie same, mniej lub bardziej.

Robię to teraz:

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

Przełącznik przypadek alternatywą byłoby oczywiście nie zagnieżdżone w if-else IE

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

Ale szukam jakiegoś bardziej eleganckie rozwiązanie jak przy użyciu Interfejs do tego z polimorficznym wsparciem, co może być rzeczą, którą mógłbym zrobić, aby uniknąć linii kodu lub odpowiedniego podejścia.

--- Edit ---

---

ja właściwie wymagać to na urządzeniu z Androidem. Ale jest to bardziej konstrukcja języka Java.

To jest mała migawka warunków, które mam ze mną. Więcej zostanie dodanych, jeśli kilka jest poprawnych. To oczywiście wymagałoby więcej, jeśli-else i tych, które mogłyby być również zagnieżdżone. W takim przypadku przetwarzanie będzie powolne.

Jestem jak na razie przechowywania wiadomości w klasie oddzielne z różnych zmiennych łańcuchowych tych Ja zachowałem statyczny więc jeśli warunek staje się prawdziwą potem wybrać zmienną statyczną z jedyną klasą i wyświetlić tę jeden. Czy byłoby to słuszne w przechowywaniu powstałych wiadomości?

Answer 1

zależności od liczby wejść warunkowych, może być w stanie wykorzystać tabelę przeglądową, a nawet HashMap, przez kodowanie wszystkich wejść lub nawet kilka stosunkowo prostych złożonych warunków w pojedynczej wartości:

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); 

Ten paradygmat ma dodatkową zaletę polegającą na stałym czasie (O(1)) złożoności, która może być ważna przy niektórych okazjach. Zależnie od złożoności warunków, możesz mieć nawet mniej oddziałów w ścieżce kodu, w przeciwieństwie do pełnowymiarowego kodu spaghetti, co może prowadzić do poprawy wydajności.

Być może będziemy w stanie Ci pomóc, jeśli dodasz więcej kontekstu do swojego pytania. Skąd pochodzą dane wejściowe? Jacy oni są?

I ważniejsze pytanie: What is the actual problem that you are trying to solve?

Answer 2

Istnieje wiele możliwości do tego. Nie wiedząc wiele o swojej domeny, chciałbym stworzyć coś podobnego (można myśleć o lepszych nazw: P)

public interface UserFriendlyMessageBuilder { 
     boolean meetCondition(FooObjectWithArguments args); 

     String transform(String rawMessage); 
} 

W ten sposób można stworzyć Set z UserFriendlyMessageBuilder i po prostu iterację nich po raz pierwszy, że spełnia warunek przekształcenia nieprzetworzonej wiadomości.

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

Answer 3

Co wydaje mi się to „Dałeś bardzo mniejszą wagę zaprojektować produkt w modułach” który jest głównym czynnikiem przy użyciu OOP Język.

np .: Jeśli masz 100 warunków i jesteś w stanie wykonać 4 moduły, to teotycznie, aby wybrać dowolną opcję, potrzebujesz 26 warunków.

Answer 4

Jest to dodatkowa możliwość, która może być warta rozważenia.

Wykonaj każde porównanie i obliczyć jego prawdę, a następnie spójrz na wynikową wartość boolean [] w tabeli prawdy. Istnieje wiele istniejących prac na temat simplifying truth tables, które można zastosować. Mam uproszczenie tabeli prawdy applet Napisałem wiele lat temu. Możesz znaleźć jego kod źródłowy przydatny.

Kosztem tego są wszystkie porównania, a przynajmniej te, które są potrzebne do oceny wyrażenia za pomocą uproszczonej tabeli prawdy. Zaletą jest zorganizowany system zarządzania skomplikowaną kombinacją warunków.

Nawet jeśli nie używasz tabeli prawdy bezpośrednio w kodzie, rozważ napisanie i uproszczenie jednego jako sposobu organizacji kodu.