Right, but only for simple things.
To me, especially with an OO design, I'd rather encourage:
// assume a calculator that only handles binary operators Operator operator = Operator.parse("+"); //throws OperatorParsingException operator.resolve(a, b);
Over
switch (operatorInput) { "+": add(a, b); break; "-": minus(a, b); break; default: throw OperatorParsingException(operatorInput); }
Now, when we get back into functional, I'm not as confident in my design, but I think I would do it like this. (But the switch statement badness is not precisely involved anyway, I'm just thinking out loud here.)
(defmulti operator (fn [op a b] op)) (defmethod operator :plus [_ a b] (+ a b)) (defmethod operator :minus [_ a b] (- a b)) (operator :plus 5 6) ; =11
Sure, but in the Operator#resolve function you will still need either an if or a switch statement. How I would do this in Kotlin:
fun resolve(a: Int, b: Int) = when(type) { // type is the operator type OperatorType.minus -> a - b OperatorType.plus -> a + b }
or:
fun resolve(a: Int, b: Int) = if(type == OperatorType.minus) a - b else if(type == OperatorType.plus) a + b else throw Exception("!?")
I think the first one is way more clear.
Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink.
Hide child comments as well
Confirm
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Right, but only for simple things.
To me, especially with an OO design, I'd rather encourage:
Over
Now, when we get back into functional, I'm not as confident in my design, but I think I would do it like this. (But the switch statement badness is not precisely involved anyway, I'm just thinking out loud here.)
Sure, but in the Operator#resolve function you will still need either an if or a switch statement. How I would do this in Kotlin:
or:
I think the first one is way more clear.