Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

How to avoid multiple if else

 
Tushar Anandani
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am having this problem that in my Service Facade for the Application we have 6 else ifs when the max length is 5....is there a work around for it...
 
Rusty Shackleford
Ranch Hand
Posts: 490
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
perhaps, post more details and some code.
 
Jesper de Jong
Java Cowboy
Saloon Keeper
Posts: 15214
36
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Who says that the max. number of else if's is 5? This is certainly not a limitation of the Java compiler. Do you have to adhere to some kind of coding standard that imposes this limitation?

IMO, coding standards should only be used as guidelines - if there is a good reason to break a rule, it should be allowed, provided that the reason is documented in a comment, for example.

If you go and invent strange code constructions to avoid breaking the coding standard, you're most likely only going to make the code worse - less readable, less maintainable.
 
Tushar Anandani
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
yeah i am using code analyzer as a coding standard tool....actually we have some ids on the basis of which we have to call various methods.So in service facade we choose the id on the basis of client's request.So if's are necessary......is there a solution....???Please help me!
 
Joanne Neal
Rancher
Posts: 3742
16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If the ids are numeric use a switch statement. If they're not numeric, then I think you can put them in an enum and then use a switch statement with the enum, but I've never done the latter so I may be wrong.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Or you could use a Map that has the ids as keys and Command objects as values.
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
5 seems a bit arbitrary, but the problem is solved with an appropriate abstraction using a strategy.
Instead of:

Prefer:

You can even write an implementation that uses the if/else to start off, but prefer a "Map-backed" strategy. You will note that above interface method is just one method of a Map<String, Integer> - it is an unfortunate attribute of OO/Java that you have to minimalise by declaring a new type - requirement leak is inherent within the paradigm.
[ August 25, 2006: Message edited by: Tony Morris ]
 
Anand Hariharan
Rancher
Posts: 272
C++ Debian VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ilja Preuss:
Or you could use a Map that has the ids as keys and Command objects as values.


How does one populate this map?
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Anand Hariharan:


How does one populate this map?




In Java 5, you would of course add the generics type declarations. Does that help?
 
Anand Hariharan
Rancher
Posts: 272
C++ Debian VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ilja Preuss:




In Java 5, you would of course add the generics type declarations. Does that help?


When you proposed using a map as an alternative, I somehow imagined that populating the map would be pretty much equivalent to the multiple if-else / switch statements.

I guess it depends on how many (different) places the OP lands up using multiple if-else statements. If it is at several places, a map would be a lot more elegant as you suggest.

respectfully,
- Anand
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Anand Hariharan:


When you proposed using a map as an alternative, I somehow imagined that populating the map would be pretty much equivalent to the multiple if-else / switch statements.

I guess it depends on how many (different) places the OP lands up using multiple if-else statements. If it is at several places, a map would be a lot more elegant as you suggest.

respectfully,
- Anand


There are more advantages than simply to prevent duplication. Using the appropriate abstraction (not necessarily a Map) provides minimalism which in turn provides adaptation to requirement change. That the implementation of the strategy is in the same place as what would otherwise be if/else is irrelevant - what is more relevant is that the implementation is free to be whatever it wants. In terms of the Map implementation, you also have the advantage of O(1) seek rather than O(n) seek for if/else.

An if else can always be abstracted to an association. Map contains one method that describes an association (and unfortunately many more which is why we have the notion of "Map-backed" gumph).
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I like the map-driven solution to separate code that I expect to change from code that I want to be stable. I populate the map from configuration so I can add new keys and commands without touching the code. The system is open for extension but closed for change.

Every time we open up code to add another else-if we run the risk of breaking it. Not touching it is a better choice any day.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic