なぜ iPhone プログラミングではデリゲートを多用するのか

iOS / iPhone プログラミングでは、デリゲートをよく見かけることになります。どうしてこんなに見かける羽目になってしまったのでしょうか。それを考えてみることにします。

まず1つ。iPhone アプリケーションでもっとも基本的なユーザーインターフェースは、おそらくテーブルビュー ( UITableView )になるのではないでしょうか。このテーブルビューの実装では、少なくとも2つのデリゲートを実装することになります。それは、UITableViewDataSource と UITableViewDelegate であり、1つのクラスで両方のデリゲートを実装してしまえば、1つのクラスしかできませんが、それでもテーブルビュー1つにつき、2つのデリゲートを実装する必要があるのです。

そして2つ目。アプリケーションにも依りますが、 NSURLConnection ではデリゲートで通信のやりとりをします。つまり、ネットワークから何かリソースを取得するようなプログラムの場合、この NSURLConnection によってデリゲートを使う必要が出てくるわけです。

他にも UIAlert など、デリゲートが出てくる場面はたくさんあります。その結果、iOS / iPhone プログラミングでは、デリゲートを多用する必要が出てきてしまっているのでしょう。

一方で、OS X はどうなっているのかと言えば、そもそも UI の基本がテーブルビューとは限らないので、iOS ほどテーブルビューを使いません。そして何よりも、 OS X では Cocoa Biding が利用できるわけで、outlet / action 接続がほとんど無くなるだけでなく、テーブルビューでデータソースをデリゲートにする必要もなくなり、デリゲートの数が少なくなります。

iOS / iPhone で Cocoa Binding が無いのは、おそらくオーバーヘッドが大きいし、バインドして値を同期させるほどの処理性能が iPhone にはないからだと考えておりますが、よりデバイスが進化した数年後には、Cocoa Binding が iPhone でも使えるようになっていてもおかしくはないと思います。

コメント投稿