＞｢Delegation｣ﾊﾟﾀｰﾝはCocoa Touchｱﾌﾟﾘｹｰｼｮﾝでよく使われます｡

Cocoa Touchのｱﾌﾟﾘｹｰｼｮﾝを作成するに際に ｢Delegation｣ﾊﾟﾀｰﾝを使うことが多いです｡


＞というのも､独自の振る舞いを実装するために､UIApplicationのような複雑なﾌﾚｰﾑﾜｰｸｵﾌﾞｼﾞｪｸﾄのｻﾌﾞｸﾗｽを定義し､ﾒｿｯﾄﾞをｵｰﾊﾞｰﾗｲﾄﾞする必要がないからです｡


｢独自の振る舞いを実装するために｣というのは､ｵﾘｼﾞﾅﾙで追加 および修正したい箇所のことです｡

通常は ﾌﾚｰﾑﾜｰｸというものの ｻﾌﾞｸﾗｽを定義したり
ﾒｿｯﾄﾞのｵｰﾊﾞｰﾗｲﾄﾞをしたりして 作成しますが､
そういう必要性がない ということですね｡

ｵｰﾊﾞｰﾗｲﾄﾞというのは ﾌﾚｰﾑﾜｰｸという ﾌﾟﾛｸﾞﾗﾑの一部の関数などの
中身を そのまま 変更したりすることです｡

継承よりも､委譲 (delegate) の方が柔軟なｹｰｽのひとつ｡

振る舞いを変えようとしている対象のｸﾗｽが複数で､それぞれが継承関係にある場合｡
例えば､｢図形｣を表すｸﾗｽがあったとします｡


ここに､｢影をつける｣という機能追加をするときに､継承で実装するとしたら､どうなるでしょう｡
継承関係の末端に､｢影付き三角形｣とか｢影付き楕円｣を実装することになるでしょう｡

図形を描画する､という振る舞いを委譲で実装されている場合､こういうふうに実装できる余地があります｡


図形の描画では､さまざまな修飾が行われるかもしれません｡
それぞれの修飾の種類ごとに､その実装を､ひとつのｸﾗｽにｶﾌﾟｾﾙ化できるかもしれません｡

修飾の種類が増えたらどうなるでしょう｡
｢影付き､回転可能な､背景画像が指定できる三角形｣なんてのをいくつも作らなくちゃいけない？
｢影をつける｣､｢回転する｣､｢背景画像をつける｣というｸﾗｽに､処理を委譲できるかもしれません｡


｢図形を描画する｣という処理を､図形の継承関係から外に出しているのを､
tdoi さんのｺﾒﾝﾄでは､｢ﾌﾟﾛﾄｺﾙ｣と表現しています｡


でも､委譲で何でも解決できるでしょうか｡
先の図形の例で言うと､描画に必要な情報は､基底の｢図形｣ｸﾗｽから取得できないと実装できません｡
また､回転させた図形の影はどうかきましょうか｡
tdoi さんのｺﾒﾝﾄでの､｢ﾌﾟﾛﾄｺﾙの境界を越えて制御することが難しい｣というのが､
この辺りの話になります｡


委譲に関する質問だったので､委譲のﾒﾘｯﾄを推し出した書き方をしましたが､
継承には､それに向いたｹｰｽがあります｡

GoF のﾊﾟﾀｰﾝで言うと､Decorator や Chain of Responsibility が､委譲ならでは､のﾊﾟﾀｰﾝで､
Template Method なんかが､継承のﾒﾘｯﾄを引き出したﾊﾟﾀｰﾝになります｡