views:

279

answers:

8

Right now I'm going to have to write a method that looks like this:

public String Calculate(String Operator, Double Operand1, Double Operand2)
{

        if (Operator.equals("+"))
        {
            return String.valueOf(Operand1 + Operand2);
        }
        else if (Operator.equals("-"))
        {
            return String.valueOf(Operand1 - Operand2);
        }
        else if (Operator.equals("*"))
        {
            return String.valueOf(Operand1 * Operand2);
        }
        else
        {
            return "error...";
        }
}

It would be nice if I could write the code more like this:

public String Calculate(String Operator, Double Operand1, Double Operand2)
{
       return String.valueOf(Operand1 Operator Operand2);
}

So Operator would replace the Arithmetic Operators (+, -, *, /...)

Does anyone know if something like this is possible in java?

+1  A: 

No this is not possible in this way.

You will need a parser to do what you want, and this can be cumbersome.

You're probably asking the wrong question, since you are getting the wrong answer.

If you are looking for a mathematical parser you might want to take a look at this project on SF: http://sourceforge.net/projects/jep/

There might be some answers in this.

Snake
+6  A: 

Method arguments in Java must be expressions. An operator by itself is not an expression. This is not possible in Java.

You can, of course, pass objects (maybe enum constants) that represents those operators, and act accordingly, but you can't pass the operators themselves as parameters.


Additional tips

Since you're just starting Java, it's best to ingrain these informations early on to ease your future development.

  • Method names starts with lowercase: calculate instead of Calculate
  • Variable names starts with lowercase: operator instead of Operator
  • Double is a reference type, the box for primitive type double.
    • Effective Java 2nd Edition, Item 49: Prefer primitive types to boxed primitives
  • Don't return "error...". Instead, throw new IllegalArgumentException("Invalid operator");

See also

polygenelubricants
Ah thank you! Coding tips are much appreciated.
James
+5  A: 

No, you can't do that in Java. The compiler needs to know what your operator is doing. What you could do instead is an enum:

public enum Operator
{
    ADDITION("+") {
        @Override public double apply(double x1, double x2) {
            return x1 + x2;
        }
    },
    SUBTRACTION("-") {
        @Override public double apply(double x1, double x2) {
            return x1 - x2;
        }
    };
    // You'd include other operators too...

    private final String text;

    private Operator(String text) {
        this.text = text;
    }

    // Yes, enums *can* have abstract methods. This code compiles...
    public abstract double apply(double x1, double x2);

    @Override public String toString() {
        return text;
    }
}

You can then write a method like this:

public String calculate(Operator op, double x1, double x2)
{
    return String.valueOf(op.apply(x1, x2));
}

And call it like this:

String foo = calculate(Operator.ADDITION, 3.5, 2);
// Or just
String bar = String.valueOf(Operator.ADDITION.apply(3.5, 2));
Jon Skeet
Enums cannot have abstract methods.
Ashish Jindal
+1, but typo in subtraction implementation and identifier of second argument.
aioobe
@aioobe: Yup, I'd just got to the identifier but had missed the implementation. @Ashsish: Yes they can, if all the values override it.
Jon Skeet
This solves my problem! Thanks for sharing your solution.In a dynamic programming language like Python, there would be an eval() method to rescue, but there is none in Java.
Kenny M.
A: 

Operators, AFAIK, cannot be passed as a parameter in any language (at least that I've come across).

Reason is that only values (either by copy or by references) can be passed as "values to parameters".

And operators represent no values.

Ashish Jindal
Operators can be passed as parameters in every functional language I know. Scala can do it on the JVM.
Daniel Pryden
Yeah, I died a little inside when I read that part. The ability to pass operators is one of those things Java-oriented people never consider, and then they find a language that supports it and hopefully it blows their minds
Michael Mrozek
@Daniel: That tells me to look into Scala :)In anycase, the operator stuff doesn't apply to Java ;)
Ashish Jindal
+2  A: 

You can either

  1. Use a functional language for JVM to implement this part of your code (clojure, scala et el), wrap lambda functions around math operators and pass those functions as parameters

  2. Get an expression evaluator for Java like http://www.singularsys.com/jep/ (and there must be many free alternatives as well)

Midhat
+3  A: 

You can't pass operators directly. You could use functors.

public double Calculate(BinaryFunction<Double, Double, Double> op, double Operand1, double Operand2)
{
  return (double)op.evaluate(Operand1, Operand2);
}
Matthew Flaschen
+2  A: 

There's only the cumbersome way of doing it with a callback interface. Something like

interface Operator {
    public Double do(Double x, Double y);
}

Then you implement the operators you need:

Operator plus = new Operator() {
    public Double do(Double x, Double y) {
        return x + y;
    }
};

And your generic method takes an Operator and the two arguments:

public String Calculate(Operator operator, Double x, Double y) {
    return String.valueOf( operator.do(x, y) );
}

You could also use an enum instead of an interface if you only need a smaller, fixed number of operators.

Thomas Kappler
Cumbersome perhaps, but this is considerably more flexible and extensible than using an enum.
Daniel Pryden
That it is. Especially since you can use anonymous classes for one-off operators.
Thomas Kappler
@Daniel: Yes, it depends on whether you have a fixed set of operators to start with. If you do, an enum is neater IMO (and allows for serialization etc). If you need the extra flexibility, the anonymous inner class bit works fine. Of course, you could always make an enum which implements the interface, to get the best of both worlds :)
Jon Skeet
@Jon: True enough. That's why I didn't say that this approach is necessarily *better*, just that it "is considerably more flexible and extensible." In many cases, "flexible and extensible" equals better, but obviously not always. (Serialization is an excellent counterexample, BTW.) It just goes to show you should never pick your design until you know the constraints of the problem!
Daniel Pryden
A: 

It would be nice, wouldn't it? But, you just can't do that. You can probably accomplish, something similar by writing your own "operators".

public interface Operator {
  Double calculate(Double op1, Double op2);
}

public Addition implements Operator {
  @Override
  Double calculate(Double op1, Double op2) { return op1 + op2; }
}

public class Calculator {
  private static Operator ADDITION = new Addition();
  private static Map<String,Operator> OPERATORS = new HashMap<String,Operator>();
  static {
    OPERATORS.put("+",ADDITION);
  }

  public String Calculate(String operator, Double operand1, Double operand2) {
    return String.valueOf(OPERATORS.get(operator).calculate(operand1,operand2);
  }
}

You get the picture how to extend this to many other operators ... and not only Doubles obviously. The advantage of my method is that you can actualy keep your method signature of accepting a String operator.

Strelok