avoiding if-else condition

[Udayan Kumar]

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]

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...

[Joanne Neal]

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

Class classExtraInfo = Class.forName(loanObject.getClass.getName() + "ExtraInfo");
ExtraInfo ei = classExtraInfo.newInstance();
ei.getExtraInfo();

[Udayan Kumar]

Hi Martijn, instanceOf is what I want to avoid.

[Ankit Garg]

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]

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]

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]

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]

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