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