きっかけ
現場で、switchについて近くの席から、あーだこーだ聞こえてきたので、考えをまとめたくなって書くに至る。
ちなみに、その会話に僕は入ってません。
だって、たいして仲良くないやつの会話に入っていったら、場の空気悪くする＆影で口撃を受けるから。
僕の実体験だから、よく分かる。
考え
僕は、断固switch反対派。
switch反対理由
オブジェクト指向ではない
どちらかというと、手続き型プログラミングと言ったほうがいい。
上から順に処理をするのが、いかにもそれっぽい。
1caseに該当する処理が、オブジェクトに当てはまるはず。
あとは、key によって、どのオブジェクトを生成するかを判定するファクトリクラスを作れば、オブジェクト指向になる。
switchは、デザインパターンで言うところの、FactoryかStorategy、Stateに置き換えが可能なはず。
デザインパターンの適用が必ずしも正解ではないけれど、switch文はいろいろ面倒な問題を抱えるので、依存性を薄く分離できるのであれば、なるべくしたほうが無難。
と、個人的に思っている。
バグを生みやすい
switch (s) {
case 1:
A;
case 2:
case 3:
B;
break;
default:
C;
break;
}
よく上記の使い方をするケースをよく見る。
ただ、要件が変わったときに、修正するとバグを生みやすい。
例えば、2 のときだけ、別な処理をしたいってなると、2のcaseに処理を追加してbreakすればいいと思ってしまうが、1のときの処理が変わってしまう。(A->Bの流れが途絶える。)
あと、実装していて、break忘れがよくあるので、開発コストも高いのでなかろうか？って思ってる。
拡張性が薄い
バグを生みやすい の流れと一緒。
バグを生みやすい＝拡張しにくいだから、同じことを言い直しているだけかも知れないな。。。
特に、case内の処理が大きくなっていくので、switchが読みにくくなるってのも、痛い。。。
可読性が悪い
改修が何回か入ってくると、case文が長くなり、それが積み重なってswitch文が長くなり、バグを混入するという結末に至る。
雑記
書いていて思ったが、開発コストが意外に高くつくのではなかろうか？
よくやってしまう、break忘れで、「何で？」ってなることがよくある。
読み返しにくいうえ、break入れたらバグる可能性も含んでいるので、やっぱり辞めた方がいいと感じた。
誰か、switchの開発コストを測った人はいるのだろうか？
switch使った場合と、if文羅列、storategy／stateパターンを使った開発コストが気になる。
思考が偏っていると思えなくもない。
逆に、switchの方がいいケースってあるのだろうか？
それがまったく思いつかない。
