aspose file tools*
The moose likes Java in General and the fly likes avoiding if-else condition Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "avoiding if-else condition" Watch "avoiding if-else condition" New topic
Author

avoiding if-else condition

Udayan Kumar
Ranch Hand

Joined: Jan 16, 2007
Posts: 66
Hi there,

I have a current service which takes a generic parent object as an input. This service is invoked by an external app.
Now based on the child object passed i have to chart the future course

So say my parent object is Loan and child objects are personal loan, home loan and auto loan.
I don't think its a good idea to have if clause for each type. Saying that I would appreciate if you could provide what would constitute a better design approach over the usage of if condition.

So accordingly at the service layer i get a Loan object. I have to check if it is personal loan then I have to introspect the input for further info. if it is home loan i have to do a database pull for assembling extra info and in case of autoloan i have to look at user input as well the database lookup.

In all 3 cases we populate a common LoanDto and pass it to LoanService. The end result of all assembly ops is the same but its the input type depending on various assembly criteria which is causing some concern.
My confusion is over having the if condition to distinguish the type of input and choose appropriate assembly operation is what I want to avoid as I will have to add more if conditions when new types spring up. Since these are passed as the input by external app I don't want to embed logic of assembling additional info in these dto type container objects.

Kindly provide suggestions.


Uday
Martijn Verburg
author
Bartender

Joined: Jun 24, 2003
Posts: 3274
    
    5

Just to be doubly clear:

Are you always passed a Loan object (and you have to do some 'stuff' to find out what it is)? Or are you passed the child of that Loan object e.g. PersonalLoan? e.g. Can you use instanceof to quickly determine which type of Loan you have...


Cheers, Martijn - Blog,
Twitter, PCGen, Ikasan, My The Well-Grounded Java Developer book!,
My start-up.
Joanne Neal
Rancher

Joined: Aug 05, 2005
Posts: 3535
    
  15
Assume the classes representing the 3 child objects are PersonalLoan, HomeLoan and AutoLoan.
Create three new classes in the same package called PersonalLoanExtraInfo, HomeLoanExtraInfo and AutoLoanExtraInfo.
Have each of these new classes implement an interface called ExtraInfo which has a method called getExtraInfo.

Then when you receive one of the child objects, you use Reflection to create an object of the appropriate class



Joanne
Udayan Kumar
Ranch Hand

Joined: Jan 16, 2007
Posts: 66
Hi Martijn, instanceOf is what I want to avoid.
Ankit Garg
Sheriff

Joined: Aug 03, 2008
Posts: 9302
    
  17

Udayan did you read what Joanne wrote. That is the solution to your problem. The code to do the extra bit of working on different type of loans is separated that way from your original business logic. So if more load types are added, you just have to add new classes to handle the working of that loan and your original business logic remains the same...


SCJP 6 | SCWCD 5 | Javaranch SCJP FAQ | SCWCD Links
Martijn Verburg
author
Bartender

Joined: Jun 24, 2003
Posts: 3274
    
    5

Udayan Kumar wrote:Hi Martijn, instanceOf is what I want to avoid.

Yup, that's what I wanted to make clear, I think Joanne's post is what you're after in that case.
Bauke Scholtz
Ranch Hand

Joined: Oct 08, 2006
Posts: 2458
Why not making use of polymorphism?

Declare the desired method in the Loan interface and let all subclasses implement it their own way. This way you just need to invoke Loan#newAbstractMethod() instead of doing instance of and casting thing.
Joanne Neal
Rancher

Joined: Aug 05, 2005
Posts: 3535
    
  15
Bauke Scholtz wrote:Why not making use of polymorphism?

Declare the desired method in the Loan interface and let all subclasses implement it their own way. This way you just need to invoke Loan#newAbstractMethod() instead of doing instance of and casting thing.


That's what I would have suggested if it hadn't been for the restriction in the last sentence of the original post.
Since these are passed as the input by external app I don't want to embed logic of assembling additional info in these dto type container objects.

I can't see that it would make much difference to anything, but my other solution avoids this.
Bauke Scholtz
Ranch Hand

Joined: Oct 08, 2006
Posts: 2458
Well, that's then his own choice: clean OO approach (polymorhphism) or nasty procedural approach (if/else/if/else/if/else). Just weight pros and cons yourself and see further. There is no other solution (although maybe the strategy or command patterns may help in this, but that's imho a bit cumbersome).
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: avoiding if-else condition