【Java進化史 第4回】switch文と設計思想 ― 分岐の向こう側にあるもの
そういえば、最近あまりswitch文を書いていない。
書けなくなったわけではない。 むしろ、書こうと思えばすぐ書ける。
だが設計を考え始めると、 どこかで立ち止まる自分がいる。
■ 手続き的思考の安心感
switchは安心だ。
条件を並べれば、 処理の流れは一目で追える。
どこで何が起きるのか、 すべてが自分の視界の中にある。
長く手続き的なコードを書いてきた身には、 この感覚は心地よい。
分岐を書く。 処理を書く。 上から順に読む。
世界が、整然と並んでいる。
■ ふと浮かぶ違和感
だがあるとき、ふと思った。
オブジェクト指向言語で、 switchをあまり見ないのはなぜだろう。
書けるのに、 あまり使われない。
それは構文の問題ではない。 設計思想の違いだ。
■ 責務という考え方
オブジェクト指向では、 振る舞いはクラスに持たせる。
条件で分けるのではなく、 責務で分ける。
「どの種類か」で分岐するのではなく、 「誰が責任を持つのか」を考える。
その結果、 分岐はオブジェクトの内部に吸収される。
外側から見えるのは、 ただの振る舞いだけになる。
■ 変更点の局所化
switchを書き始めると、 同じ条件分岐が別の場所にも現れることがある。
仕様変更が入るたびに、 その条件を探して回る。
変更点が、散らばる。
一方で、責務を適切に分けた設計では、 変更は一か所に閉じ込められる。
変更点の局所化。
それは地味だが、 長く保守する現場では大きな意味を持つ。
■ 拡張に開き、修正に閉じる
新しい種類が増えたとき、 switchはcaseを増やす。
既存のコードを修正する。
だが理想とされる設計は、 拡張に開き、修正に閉じる。
既存部分に手を入れず、 新しい要素を追加することで対応する。
それがOCP（Open/Closed Principle）と呼ばれる考え方だ。
理屈は理解している。
だが、実践は簡単ではない。
■ 設計の重さ
責務を分ける。
将来の変更を想像する。
インターフェースを定義する。
switch一つで済む場面でも、 設計は少し重くなる。
正直に言えば、 急いでいるときほど、 switchの安心感に戻りたくなる。
条件を書けば、すぐに動く。
目の前の問題は、すぐ解決する。
■ 未来の自分への負債
だが安易な分岐は、 未来の自分への負債になることがある。
仕様が増え、 条件が増え、 分岐が増え、 修正箇所が増える。
そのとき向き合うのは、 過去の自分の判断だ。
設計とは、 未来の自分との対話なのかもしれない。
■ 分岐の向こう側
switchを書かなくなったのは、 構文の問題ではない。
分岐よりも、 責務を考える時間が増えただけだ。
それが成長なのか、 ただ慎重になっただけなのかはわからない。
だが少なくとも、 設計という重みを意識するようにはなった。
分岐の向こう側にあるもの。
それを考えることが、 オブジェクト指向という思想なのだと思う。
0 件のコメント:
コメントを投稿