Java: long list of conditions, what to do?

Question

I need a suggestion for a proper approach to applying conditions in Java.

I have 100 conditions based on which I need to change the value of the String variable that will be displayed to the user.

approximate condition: a<5 && (b>0 && c>8) && d>9 || x!=4 a<5 && (b>0 && c>8) && d>9 || x!=4

Additional conditions exist, but the variables are the same.

I'm doing it right now:

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

An alternative to a case switch will obviously be nested in if-else ie

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

But I'm looking for some more elegant solutions, such as using an interface for this with polymorphic support. What could be, what can I do to avoid lines of code, or what should be right.

--- Edit ---

---

I really require this on an Android device. But its more java built here.

These are small snapshots of the conditions that I have with me. More will be added if some of them are correct. This will obviously require more if-else, and they can also be nested. In this case, the processing will be slow.

I save messages in a separate class with various string variables that I saved, so if the condition becomes true, then I select a static variable from a single class and show that one. Would it be correct to save the resulting messages.

Answer 1

Depending on the number of conditional inputs, you can use a lookup table or even a HashMap by encoding all the inputs or even some relatively simple complex conditions in one value:

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

This paradigm has the added benefit of constant time complexity ( O(1) ), which may be important in some cases. Depending on the complexity of the conditions, you may even have fewer branches in the code path on average, unlike full-blown if-then-else spaghetti code, which can lead to increased performance.

Perhaps we can help you if you add more context to your question. Where does the source data come from? What are they?

And the more important question: What is the actual problem that you are trying to solve?

Answer 2

There are many possibilities for this. Unaware of my domain, I would create something like (you can think of better names: P)

  public interface UserFriendlyMessageBuilder { boolean meetCondition(FooObjectWithArguments args); String transform(String rawMessage); } 

That way, you can create a Set from UserFriendlyMessageBuilder and simply UserFriendlyMessageBuilder over them for the first one that satisfies the condition for converting your raw message.

 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

It seems to me that “you pay very little attention to product development in modules”, which is the main factor in using the OOP language.

for example: If you have 100 conditions, and you can make 4 modules, then theothically for anything, you need 26 conditions.

Answer 4

This is an additional opportunity worth considering.

Let's take each comparison and calculate its truth, and then look at the resulting Boolean [] in the truth table. There is a lot of work to simplify truth tables that you could apply. I have a simplification of the truth table applet I wrote many years ago. You may find its source code useful.

The cost of this is all comparisons, or at least those needed to evaluate an expression using a simplified truth table. The advantage is an organized management system for a complex combination of conditions.

Even if you are not using the truth table directly in your code, consider writing and simplifying it as a way to organize your code.