私は、デリゲートは本質的に別のオブジェクトがメッセージを渡すことができるオブジェクトであり、他のクラスの代わりに使用されることを理解しています。したがって、例えば、UITableViewDelegateは、UITableViewの特定のイベントを検出するために使用できるメソッドを持っています。これは非常に便利です。実際、私は以前のiOSプロジェクトで代理人を多く使用していました。これは好奇心です。iOSにデリゲートが存在するのはなぜですか？
デリゲートクラスのメソッドは、デリゲートが存在するクラスに委任？
具体的には、実際のクラスでこれらのメソッドを使用する方が便利でしょう（UITableViewなど）。
おそらく、それは構造的にはより便利ですが、拳のような外観からは直感的ではないようです。
一般的に、合成は継承より強力です。継承は多くの微妙な問題を引き起こしますが、最も一般的なのはdiamond problemですが、他にも多くの問題があります。
委任はストラテジーパターンの特定の定式化に過ぎず、継承ではなくコンポジションでオブジェクトを拡張することができます。問題の具体的な例として
、そしてあなたが継承を使用するときにダイヤモンドの問題はでゾッどのように、このことを考慮してください。FetchRequestDataProvidingと呼びます。FadeInTableViewにラップします。ここでは、両方が必要なので問題があります。だから私たちは複数の継承が必要です。また、複数の継承はPandoraのあいまいさの箱です。
しかし、私がFetchRequestDataProvidingをデリゲートとして振る舞う別のオブジェクトにすると、そのすべてが排除されます。デリゲート/戦略としてFadeInAnimatingを打ち破ることで、実際にはもっと強力なものにすることができました（ただし、UIViewには今日その力はありません）。
ObjCでは、「構成は継承よりも強力です」は、かなり浅い継承ツリーと多くの代理人に共通することを示しています。 Swiftは継承のないプロトコルと構造体でこれをさらに進めます。これは、継承が悪いことを意味するものではありません。 （Goのような言語は完全に回避されますが、興味深いことに埋め込みのためにダイヤモンドの問題に直面していますが）多くの価値があります。しかし、疑わしいときは、構成がより強力なツールになります。
しかし、テーブルビューはそのデータについて何も知らないので、ビューコントローラ（通常）はテーブルビューのデータソースです。 – rmaddy
'UITableViewDelegate'メソッドが' UITableView'のメソッドであれば、セルが選択されたことをどのように通知されますか？ – dan
'UITableView'はビューです。モデルについて知ってはいけません。そこで、どのくらいの数のアイテムが必要か、どのコンテンツがあるかなどについて、 'ViewController'に問い合わせます。それは責任を分けます。 – shallowThought