bakaid: 200801152
どういうわけか、モデルがある: class Model { ... } で、どういうわけか、Dialogのサブクラスがある: class ADialog extends Dialog { ... } で、どういうわけか、モデルがそのダイアログのことを 知っている: class Model { private ADialog adialog; ... } もちろん、それがモデルの中のどこかで使われてる: class Model { public void doit() { adialog.showResult(); } } ここで、どういうわけか、ダイアログを新しくすることに なった。多分、デザインがお気に召さないとか何かだろう。 で、どうするか? まず、空っぽのインターフェイスを用意する: interface ADialogIf { } 名前はチョーテキトーだからマネしないように (笑)。 で、それを使うようにモデルのほうを変える: class Model { private ADialogIf adialog; ... } ここでコンパイルすると、もちろんエラーが出る。で、 まず、インターフェイスのほうでメソッドを宣言してやる: interface ADialogIf { public void showResult(); } ここでまたコンパイルする。2つのエラーが1つになった。 今度はダイアログのほうでインターフェイスを実装してやる: class ADialog extends Dialog implements ADialogIf { ... } ここでまたコンパイルする。今度はコンパイルが通る。 次に新しいほうのダイアログが登場する: class BDialog extends Dialog { ... } とりあえず、こいつでさっきのインターフェイスを実装 する: class BDialog extends Dialog extends ADialogIf { ... } もちろん、モデルで使うことにする: class Model { ADialogIf adialog; ADialogIf bdialog; Model() { adialog = new ADialog(); bdialog = new BDialog(); } } これでコンパイルするとエラーになる。新しいほうでは まだインターフェイスのメソッドを実装してないから。 前のダイアログのメソッドをパクる: class BDialog extends Dialog extends ADialogIf { public void showResult() { ... } } こういう感じでコンパイルが通るまで、古いダイアログの メソッドを新しいほうにパクっていく。もちろん、コピペ だけじゃ不十分だろうから、コードもよく読んでおく。 それと、これでインターフェイスは不要になった。古い ダイアログと一緒に消してもいいし、残してもいい。 結局何がいいたいかっていうと、静的な型っていうのは、 実践的な設計の道具だっていうこと。分析にしか使わない なんてバカげてる。未実装なメソッドでコンパイル・ エラーが出るんなら、それがそのままTO DOリストにもなる。 こういうコンパイラの使い方をすると、しょっちゅう コンパイルすることになる。そしてそれは正しい。 まぁ、頻繁にやらないのが間違いだとはいえないけど。 -- で、少なくとも自分にしてみれば、上みたいな主張じゃ ないと、静的型のメリットって感じられないんだよな。 typoがどうたらとか、ドキュメンテーションがどうたら とかはどうでもいい。動的言語でも大した問題になん ないから。 で、自分にしてみれば、上みたいな作業の進め方は、 できなきゃできないで何とかなると思ってるし、動的 言語には動的言語のやり方があると思ってる。それは 多分に気分的なもの、『気楽さ』とか『素早さ』といった ものだけど、それだけでも静的な型を捨てる価値はあると 思ってる。 -- ヘンな言い方だけど、静的な型でも、ダイナミックに 生まれ、そして消えていくもんなんだね。ドメインの 中にある型なら長生きするだろうけど、でも、それだって いつ消えるかわからない。必要になれば新しい型が生まれ、 いらなくなったら消えてゆく。設計っていうのは、そう いう型の新陳代謝を促すということでもあるんじゃないかな。
Copyright © 1905 tko at jitu.org