やっぱりペンギン許さん

ペンギン許さんペンギン許さん - hitode909の日記

こんな記事があった。 でも、自分はこの記事とは少し考え方が違う。

たとえば鳥類の飛行経路を観察するアプリケーションを作る場合、「最初はやっぱりスズメに対応しましょう。」とか「いやカラスも対応しようよ」みたいになる。で、スズメとカラスに対応するわけだけど、「いや待ってくれ。このアプリケーションは鳥類の飛行経路を知りたいわけだから、我々が扱うべきなのは鳥類なんじゃないの」みたいな話になって、鳥類クラスができる。ここで「いや、鳥類じゃなくて動物を扱うんじゃないの」みたいな議論にはならない。だってユースケースに動物の飛行経路を知りたいとかないから。ここは未来予知の話になる。「いやモモンガもそのうち必要になるでしょ」「あ、そっか〜〜〜」みたいな。つまり「このアプリケーションの要件として将来的にモモンガなど、鳥類以外も扱うかどうか」という話。

でも多分、鳥類の飛行経路を観察するアプリケーションを要望した顧客が「モモンガにも対応してよ」ということはかなりレアだと思うし、そこは顧客に念押しする。「我々は例えばモモンガみたいな飛行可能な別の動物に対応する予定はありませんよ」「あ、はい大丈夫です。(いや普通にいらないし...)」となる。

でも、ペンギンは飛べないから get飛行経路 メソッドは例外を吐く。 顧客は入力としてペンギンを入れてくる可能性はある。 結局許すことはできない。

こういう時はどうしたらいいんだろうか。 "interface 飛行可能" を継承した "interface 飛行可能鳥類" を実装したらいいんだろうか。 これは直行する概念な気がするから class スズメ implements 飛行可能, 鳥類 みたいな感じかな。 入力チェックのときは if (bird instanceof 鳥類 && bird instanceof 飛行可能) みたいな感じなのかな。