| ||
|
|
第6章 デザインパターン |
| ||
| ホーム | メール | |
| 目次 | < 前ページ 次ページ > | |
前章でも少し説明しましたが、この章でもデリゲートというデザインパターンの説明を続けたいと思います。
MyClipはMVCに準拠してモデルとビユーとコントローラというそれぞれの役割のオブジェクトを分立させて構築しています。しかしビュー（Text View）で編集されたデータをどのタイミングでモデルへ送るのでしょうか。言いかえれば「何をきっかけとしてモデルへデータを送る」のでしょうか。この「きっかけ」のことをプログラミング用語ではトリガー（引き金）と呼びます。
まず考えられる方法は Text View のサブクラスを作って、トリガーとなるメソッドを新しく定義するという方法です。継承というのはOOPにとって大きな特徴です。これを利用しない手はないでしょう。そして実際に多くのOOPではこの手法を使います。ここで勘違いしやすことは「トリガーとなるメソッドを最初から作っておけば良いではないか」と思うことです。たしかにその通りです。そして実際に継承したサブクラスでトリガーメソッド（多くの場合、トリガーメソッドはアクション actionという名前にされることが多いみたいです）を定義するのではなくスーパークラスでアクションメソッドが定義されています。しかし、その実装はどうなっているのでしょうか。ほとんどのビューはクラス設計時の段階ではどこで何の目的で使われることになるのか分かりません。したがってアクションというメソッドを定義しておくことはできても実装を記述することはできないわけです。そこで多くのOOPのビュークラスではアクションというバーチャルメソッドを用意しておき、そのビュークラスを継承したサブクラスでアクションメソッドをそのアプリケーションに合わせて実装します。あれ？やっぱりサブクラスを作らなければならなくなりますね :-)
どちらにしてもこの考え方ではサブクラスを作らなければいけなくなります。オブジェクトは大きくなればなるほどCPUへの負荷が増えてきます。そこでObjective-Cでは3章のオブジェクトの節で述べたように自分に実装されていないメソッドについては継承という方法を使うのではなく外注に出すことにしています。この外注に出す方法の代表格のひとつがこの章のタイトルにもなっているデリゲートです。
ではデリゲートとはどういうものでしょうか。簡単にまとめると次のようになります。
この説明でご理解いただけたかどうか分かりませんが、文章で説明するよりも実際にMyClipにデリゲートを搭載してみましょう。そのほうがきっと分かりやすいと思います。
しかしその前にもうひとつデリゲートに関してとても大事な話しがあります。後ほど各クラスのリファレンスというものを見てもらいますが、多くのクラスに多くのデリゲートメソッドが宣言されています。通常は宣言されたメソッドは必ず定義もされていなければなりません。継承したメソッドなどはわざわざ定義を記述しなくても定義されていることになっています。ですから、ついついこのことを忘れがちになると思います。しかしデリゲートメソッドはデリゲートメソッドの中から採用したいメソッドのみをdelegateインスタン変数に接続されたオブジェクトに定義（実装）すれば良いことになっています。このことはかなり特殊なことでとても大事なことです。実際にこの特殊な仕組みのためにデリゲートメソッドの宣言を自作のクラスに組み込むことはまずないでしょう。
| 目次 | < 前ページ 次ページ > |