• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Paul Clapham
  • Ron McLeod
Sheriffs:
  • Jeanne Boyarsky
  • Liutauras Vilda
Saloon Keepers:
  • Tim Holloway
  • Carey Brown
  • Roland Mueller
  • Piet Souris
Bartenders:

avoiding if-else condition

 
Ranch Hand
Posts: 66
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
author
Posts: 3285
13
Mac OS X Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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...
 
Rancher
Posts: 3742
16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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


 
Udayan Kumar
Ranch Hand
Posts: 66
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Martijn, instanceOf is what I want to avoid.
 
Sheriff
Posts: 9709
43
Android Google Web Toolkit Hibernate IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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...
 
Martijn Verburg
author
Posts: 3285
13
Mac OS X Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Ranch Hand
Posts: 2458
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 3742
16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 2458
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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).
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic