Life is Really Short, Have Your Life!!

ござ先輩の主に技術的なメモ

delegateとGUIプログラミングについて書いてみる

その昔、僕はこんな本を買った。前職の会社のどっかに眠ってるつもり。捨てられたかも。

FLASH OOP (Advanced Web design books)

FLASH OOP (Advanced Web design books)

当時僕はFlashをやる部に配属され、とある外注様のFlashのフレーム1つ1つにびっしりかかれたムービークリップにべた書きされたソースを見て、「このコード書いたやつしね!全体の処理が全くみえねぇ!リンケージってしらねーのか!」と吠えた記憶がある。2004年のことだ。

GUIプログラミングはユーザーの操作に対して、

  • どんなイベントを発行して
  • どんな引数を渡して
  • どうやってモデルを更新して
  • 画面に処理を返すのか

というのがポイントであると思う。結局全ての処理はユーザー操作によって引き起こされ、結果をユーザーに返さなくてはならない。

で、まぁ似たような処理ってのが当然起こりうるし、このイベントはあいつが受けて、あのイベントはこいつが受けたい、UIが持ってるイベントは1個だけど、俺的にはそのイベントをラップして2つの別のイベント起こしたいとか、そんなことが絶対出てくる。SingleClickとDoubleClickがその典型。

また、あるオブジェクトのこの座標が動き始めたらイベント発火、みたいなのも当然出てくる。startMove/onMove/stopMoveとか、そんなかんじ。

flashの場合は(AS2.0だけど)Eventってクラスがあり、そこに俺EventクラスとEventHandlerを用意して、EventをHandlerがdispatchすることでユーザーのイベントをオブジェクト化しふるまいを定義する。で、UIが持ってるイベントをラップして自分がイベントを起こすことで、イベントが増えても減っても既存コードの変更は無いようにしよう、としている。

こういうイベント設計にした上でモデルを決めないと、flashは貼り付けたオブジェクトに直接コードがかけるため、大変苦労した。その点iPhoneは楽だ。

objective-cの場合はdelegateというものがある。簡単に言えばあるクラスが持ってるイベントが発火されたら誰がそれを受けるのかを、クラスの継承関係全く関係なしに指定できるというもの。イベントのコールバックは誰が受けるんですかー、という指定を自由に行う。

慣れてくると俺Delegateを用意して、子供のオブジェクトのイベントをdelegateとして設計することで(プロトコルという演算子がある)、イベント発火の処理を1つの親オブジェクトが行うことで、リソースを軽減できる。メモリ少ないし。サムネイルクリックしたら親のページが変わるとかが典型。

・・・・そんなことをAppleのScrollViewSuiteのコードを読みながら思いました。あのサンプルすげー勉強になる。

が、それでも僕はobjective-cが好きになれない。

この辺のネタはだいちゃんが好きそうだなぁ。