オーバーライドバグこんなバグをやっちった。Foo#convert0は呼ばれない}これは、ダックタイピングは......というのと同じ種類の問題のように見える。メソッドにオーバーロードがあるため、異なるシグネチャで書いてしまってもコンパイルは通るからだ。解決できるだろうか?それ抽象という方法がある。s)が未定義でコンパイルエラー}が、実際にはある長い長いデータをばしばし切り分けていくベルトコンベア的なシステムなので、Baseクラスにデフォルトの実装をしなけりゃやってられない(convert0メソッドからconvert365メソッドまであるという感じ)。いうか、具象クラスのほとんどすべてのメソッドが空実装になる。いうことは、機械的な空メソッドの実装を行う必要が出てくるため、結果的に、同傾向のバグが入りかねない。何よりも、あまりにもDRYじゃない。空メソッドを実装した具象メソッドがたくさんできてしまうからだ。Baseにしても、したがって話は変わらない。いや、すべてのメソッド呼び出しが走るテストを書かないのが悪いというのはもっともだけど、それは置いておいて。}}あまりに意味不明瞭かも知れない。実装バランスからはそれほど悪くはないかも知れない。定義済みメソッドはむちゃくちゃ多いが、オーバーライドするメソッド数はそれほど多くはないからだ。パターンがあるので、意味不明瞭さはすぐに解消するだろう。この実行時には意味を持たないsuper呼び出しを書くというのは、結局規約の問題なので忘れてしまっても意識的に省略してもビルドはできるし、たいていはうまく動く。良い防御方法とは言えないのではないか。問題は呼ばれるべきメソッドが呼ばれていないということだ。したがって、呼ばれるべきではないメソッド側では対処できないだろう。}}というか、こんなことするなら、抽象メソッドにするほうが良い。し、それは現実的ではないと否定したばかりだ。書いているうちに、可視化ツールというアイディアが生まれた。オーバーライドしてあるメソッドとそうでないメソッドが色で区別される。コメントといった、静的なというか言語仕様に基づいた色分けはしてくれるのは知っている。これが役に立つのは(読みやすいとかは別にして)、コメントが別の色になるってやつだけだ。*/を持つ腐ったプログラムを眺める時に役に立つのは知っている。なく、あるいはそれに加えて、継承についての色分けがあれば、少なくてもこの手のバグは防げる。(overrideキーワードの記述を必須にするというC#の方法もあるな。これはJavaの話だし、overrideキーワード必須は逆に面倒で忘れやすいし、しかも忘れても実行時に変だと気づくだけで、後からソース読むときの役にしか立っていないように思える)というか、こういう色付けするエディターってすでにありそうな気がしてきた。elispで書きたくはないし。メキシコのディエゴじゃなさそうだし。02:41)子側にこまめに@Override付けるのが好きですが、忘れればアウトですね。