日々の破片

_ 東の空が赤い

太陽が昇るからだ

西の空が赤い

太陽が沈むからだ

渡河の最中、太陽が昇りきる頃、舟が沈む

　（中国の黄色い大地）

11時45分頃がいいね

　（サティ）

午前8時、9時の太陽のようにはつらつとしている

_ ワンクリックホスティングサービス

_ 設計者ではなく実装者の立場で考えて見る

デリゲート：VS.NETでWindows Form使う場合には（ほとんど）意識せずにイベントの通知を受けられるから、とても便利に見える。

VS.NETでイベント受信メソッドをIDEから生成すると次のようになる。

// これはForm#InitializeComponentに自動で追加
this.button1.Click += new System.EventHandler(this.button1_Click);
// このメソッドが追加
private void button1_Click(object sender, System.EventArgs e)
{
// ここが記述個所		
}

もし、マウスの状態に関する情報を得たければ、これではだめで、Button#MouseDownイベントを使わなければならない。

// これはForm#InitializeComponentに自動で追加
this.button1.MouseDown += new System.Windows.Forms.MouseEventHandler(this.button1_MouseDown);
// このメソッドが追加
private void button1_MouseDown(object sender, System.Windows.Forms.MouseEventArgs e)
{
// ここが記述個所		
}

で、これが何を意味するかと言えば、Buttonオブジェクトを利用する側にとっては、なんにも考えなくても（選択は必要だが）良いということだ。イベントへデリゲートを登録する部分はシュリンクされて隠された部分に自動生成されて、直接イベント処理の記述個所にカーソルが来るし。

しかし、Buttonクラスを実装する場合には、必要に応じて各種引数を持ったイベントの実装が必要だということになる。それはあたりまえだ。ただし、それらは、同じクラス内のバラバラのイベントとして実装することになり、多重継承ができないC#の場合、ほとんどの場合、ばらばらに複数実装することになる。

インナークラスの場合だと、呼び出し側はこんな感じ。

button.addMouseListener(new MouseListener() {
 public mouseClick(MouseEvent e) {
   ...
 }
 ....
});

エディターを使って直接記述することを考えると、このほうが楽なのは、イベントのレシーバの登録と受信メソッドの記述が同時に同一個所でできることだ。IDEを使う場合は、後述。

実際は、どうでも良いことなんだが、デリゲートの記述でVS.NETがサポートしてくれないタイプのやつははっきり言って、面倒だ。たとえば、非同期デリゲートは嫌いだ。だって面倒くさいから。

private delegate void FooHandler(int arg);
private void Foo(int arg)
{
   Console.WriteLine(arg * 3);
}
...
new FooHandler(Foo).BeginInvoke(3, null, null);

非同期デリゲートを使う局面というのは、放り投げっ放しのワーカスレッド起動みたいなのがほとんどだから、呼び出し地点で何を行うかの記述が見たいはずなのに、デリゲートとメソッドの定義を外部に置いた上で、実際の呼び出しの記述を行うことになる。

いっぽう、無名インナークラスの

final int arg = 3;
new Thread(new Runnable() {
   public void run() {
       System.out.println(arg * 3);
   }
}).start();

は、楽だ。

やはり、デリゲートの主眼は、IDEベースでの開発しやすさにあるんじゃないかと思う。

実際、JBuilderでEventListenerを実装させてみると、VS.NETでデリゲートを使用したのと同じようなコードの生成となる。

// 自動生成
button.addActionListener(new ActionListener() {
   public void actionPerformed(ActionEvent e) {
      button1_actionPerformed(e);
   }
});
....
void button1_actionPerformed(ActionEvent e) {
  // ここに記述
}

地獄のForteの場合(個人的にはお金があるのでJBuilderを購入してるんだけど、と言ってもバージョン6で打ち止めたが、会社はお金がないのでForteのコミュニケーションエディションだったりして)、外出ししないため、修正不可な部分にモーダルダイアログで直接埋め込ませる(だからヘルプの参照もできないし、インテリセンスも存在しない)ので、まだJBuilderのほうがましだが、なんか無駄なコードに見える。

で、どうでも良いと思ってるのは、結局、ユースケースが違うんだよね。

C#でのユースケース：

プログラマ　→VS.NETで開発する　プログラム

Javaでのユースケース：

プログラマ　→エディターで開発する　プログラム

だから、C#でIDEが利用できない局面では面倒だし、JavaでIDEを利用したい局面では地獄のようにイライラする、というだけのことだ。