Which approach is better & why?

[Shravan Payasam]

Approach 1:

public class Operator {
	
	public double performOperation(int arg1, int arg2, char op) {
		double result =0;
		switch (op) {
			case '+' : result = arg1 + arg2;
			case '-' : result = arg1 - arg2;
			case '*' : result = arg1 * arg2;
			case '/' : result = (arg2==0) ? 0.0 : arg1 / arg2;
		}
		
		return result;
	}

}

Approach 2:

public class Operator {
	
	public int add(int arg1, int arg2) {
		return arg1 + arg2;
	}
	
	public int subtract(int arg1, int arg2) {
		return arg1 - arg2;
	}
	
	public int multiply(int arg1, int arg2) {
		return arg1 * arg2;
	}
	
	public double divide(int arg1, int arg2) {
		return (arg2==0) ? 0 : arg1 / arg2;
	}

}

Are there any real advantages of choosing one over the other?

[Bear Bibeault]

performOperation(1,2,'@');

Does that help you decide?

[Shravan Payasam]

I can change the method this way. Other than poorly documented method signature, is there any other difference?

public double performOperation(int arg1, int arg2, char op) throws UnknownOperationException {
		double result =0;
		System.out.println("Performing operation");
		switch (op) {
			case '+' : 
				result = arg1 + arg2;
				break;
			case '-' : 
				result = arg1 - arg2;
				break;
			case '*' : 
				result = arg1 * arg2;
				break;
			case '/' : 
				result = (arg2==0) ? 0.0 : arg1 / arg2;
				break;
			default  : 
				throw new UnknownOperationException("Only math operators should be used + , - , x, /");
		}
		return result;
	}

[Jeff Verdegan]

Shravan Payasam wrote:I can change the method this way.

I think the point was that if you had taken approach #2, this would not even be an issue.

[Rob Spoor]

Since when is 5 / 0 equal to 0? Just return Double.NaN for doubles and let the ArithmeticException be thrown for ints.

[Bear Bibeault]

Shravan Payasam wrote:I can change the method this way.

And you feel that is acceptable?

[Winston Gutkowski]

Shravan Payasam wrote:I can change the method this way. Other than poorly documented method signature, is there any other difference?

Yes. One's procedural and the other is (at least partially) Object-oriented.

Consider a new "power of" ('^') function. Your second class's method could be easily written in terms of its others (reuse), but you can't get around that extra case in your first.

Basically, both are flawed, but the first one is doubly so, because it is a classic case of "dispatch code". And dispatch code is precisely what object-orientation was designed to eliminate.

Winston

[Shravan Payasam]

Rob Spoor wrote:Since when is 5 / 0 equal to 0? Just return Double.NaN for doubles and let the ArithmeticException be thrown for ints.

Point taken.

Although that is not the subject of the question.

[Shravan Payasam]

Bear Bibeault wrote:

Shravan Payasam wrote:I can change the method this way.

And you feel that is acceptable?

By changing the method that way, what I meant is, I know that it will be break with that kind of input.
But I wanted to get more differences like the one that Winston cited.

@Winston: I guess, I'm convinced with your answer. But what did you mean by

Your second class's method could be easily written in terms of its others.

Would you mind explaining with an example?

Also, you said, both are flawed, I'm curious to know what is wrong with the Approach 2? What am I missing?

Thanks in advance
Shravan

[Bear Bibeault]

Shravan Payasam wrote:By changing the method that way, what I meant is, I know that it will be break with that kind of input.

Which is a problem. A big one.

But I wanted to get more differences like the one that Winston cited.

There are many problems with the first approach -- I'm pointing out just one of them.

The 1st rule of user interface, which also happens to be the first rule of APIs: don't let them do it wrong in the first place!

[Winston Gutkowski]

Shravan Payasam wrote:@Winston: I guess, I'm convinced with your answer. But what did you mean by

Your second class's method could be easily written in terms of its others.

Would you mind explaining with an example?

OK, but it's probably not the best:

public int pow(int arg1, int arg2) {
   int answer = 1;
   while (arg2-- > 0) {
      answer = multiply(answer, arg1);
   }
   return answer;
}

(I leave you to work out what to do with negative powers and 0⁰ )

TBH, it doesn't make much sense with primitives; but do you see that the code would be the same for almost any generic "integer" class? - indeed, arg1 could be any kind of real number.

Also, you said, both are flawed, I'm curious to know what is wrong with the Approach 2? What am I missing?

Have a look at the BigInteger class, because it has exactly the same methods as your 2nd example. The only difference is that they're built into the behaviour of the class, rather than being "utilities".

HIH

Winston