As a Senior Developer, I hate switch functions. (Especially if they don't auto-break.)
They were a mistake to add to C, especially with the fall through. It's a bad construct that unnecessarily simplifies an if/elseif/else construct while enabling mistakes and unclear flow.
They are doubly a mistake in "OO" languages. They encourage thinking that breaks the "Tell, don't ask" model.
Yes, they're old and they served their purpose when optimizing compilers weren't as good and disk space for storing source code was expensive. I say that we should avoid 'em and teach others to do the same.
(I do not argue that switch is sometimes easier to read than a forest of if/elif/else. I just think the dangers introduced by fall-through switches is too high to ignore.)
I am a developer with a passion for testing. I've been coding for 14 years and I want to share my experience and learnings with other developers to help them write better software.
I'll be honest with you, I've never really used them. I agree they don't seem to suit OOP and I'm not sure they can comply with the single responsibility principle.
They can be quite useful traversing through possible enum values. It kinda depends how the language implements switch functions. I program a lot in Kotlin and I like how they have implemented it (no need to break and you can use mutliple possible values which means no falling through kotlinlang.org/docs/reference/cont...)
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.)
DIGRESSION/SLIGHTLY OT, FEEL FREE TO DISREGARD
As a Senior Developer, I hate switch functions. (Especially if they don't auto-break.)
They were a mistake to add to C, especially with the fall through. It's a bad construct that unnecessarily simplifies an if/elseif/else construct while enabling mistakes and unclear flow.
They are doubly a mistake in "OO" languages. They encourage thinking that breaks the "Tell, don't ask" model.
Yes, they're old and they served their purpose when optimizing compilers weren't as good and disk space for storing source code was expensive. I say that we should avoid 'em and teach others to do the same.
(I do not argue that switch is sometimes easier to read than a forest of if/elif/else. I just think the dangers introduced by fall-through switches is too high to ignore.)
I'll be honest with you, I've never really used them. I agree they don't seem to suit OOP and I'm not sure they can comply with the single responsibility principle.
They can be quite useful traversing through possible enum values. It kinda depends how the language implements switch functions. I program a lot in Kotlin and I like how they have implemented it (no need to break and you can use mutliple possible values which means no falling through kotlinlang.org/docs/reference/cont...)
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.