現在C#で仕事をしているのですが、酒井さんはどのくらい振る舞いが増えた時にポリモーフィズムを使いますか？
アーリーリターンできるような処理であればポリモーフィズムは使う必要ないですか？

Question

酒井潤 · Accepted Answer

ここは「振る舞いが何個増えたら使うか」というより、if文で分岐している理由が“種類の違い”になっているかで判断することが多いです。

たとえば、

「ユーザー種別によって処理が変わる」
「決済手段によって計算方法が変わる」
「通知方法によって送信処理が変わる」

みたいに、対象の種類ごとに振る舞いが増えていくなら、比較的早い段階でポリモーフィズムを検討します。

逆に、単に条件分岐があるだけで、

「nullなら返す」
「不正値ならreturnする」
「前提条件を満たさないなら処理しない」

みたいなものは、これはポリモーフィズムで解く話ではなくて、普通にアーリーリターンでいいです。

つまり、アーリーリターンとポリモーフィズムは競合するものではなくて、役割が違います。

アーリーリターンは、ガード節として処理を読みやすくするためのものです。
ポリモーフィズムは、種類ごとの振る舞いを分離するためのものです。

なので、アーリーリターンできる処理ならポリモーフィズム不要かというと、そういう話ではありません。
中に本質的な「種類ごとの差」があるなら、アーリーリターンを書いた上で、その先をポリモーフィズムにすることも普通にあります。

実務感でいうと、こんなイメージです。

最初はif文で書きます。
ただ、そのifやswitchが何度も出てきたり、分岐ごとに修正が入りやすくなったり、追加時に既存コードを毎回触るようになったら、そこでポリモーフィズムに寄せます。

特に、

「今後も種類が増えそう」
「分岐の中身がそれぞれ長くなってきた」
「同じ条件分岐が複数箇所に出てきた」

このあたりが見えたら、かなり使いどころです。

逆に、分岐が1か所しかなくて、今後も増えないし、各処理も数行で終わるなら、無理にポリモーフィズムにしないです。そこはシンプルにif文の方が読みやすいことも多いです。

要するに、判断基準は「分岐の数」そのものより、その分岐が将来も増え続ける性質のものかどうかです。

かなり雑に言うと、

アーリーリターンは読みやすさのために使う。
ポリモーフィズムは変更に強くするために使う。

この整理で考えると、だいぶ判断しやすいと思います。

Ask Jun