とくにMacやiPhoneのプログラム開発で最初にわからなくなるのがこのあたり。Appleもそれは理解していて、Your First Mac Applicationの中のUnderstanding Fundamental Design Patternsという章にまとめてあります。
僕もまだ慣れてないので、その文章を読んでの現時点での理解を下にまとめておきました。
Model-View-Controller
その昔、僕がBASICでプログラムを書いていたときにはデータもコードも一緒くたで、すぐにスパゲッティ・コードになったものでした。Javaのようなオブジェクト指向言語を使うようになって、データ構造部分とその表示部分とは切り分けた方がいいと学びました。
たとえばRPGを作っているときに、体力点とか技術点のような主人公の基礎データを保管・管理する部分と、それらを画面に棒グラフなどで表示する部分は別のプログラムに分けておいたほうが良いよ、ということです。
それをもう一歩進め、データ構造（Model）、表示（View）、それら二者間のやりとり（Controller）の3つに分けたのがMVCです。Controllerは、データが更新されたから表示を変化させるとか、画面上のボタンがクリックされたからデータを書き換えようとか、データ部分と表示部分（入出力）の間で、ちょこまかと働きます。
Delegate
代理人とか委譲とか訳されていますが、僕のイメージでは後見人とか保護者です。オブジェクトと直接やりとりするのではなく、間に後見人を挟んでコミュニケーションをとることで、お互いに面倒な思いをしなくて済む（もしくはオブジェクトを保護できる）イメージ。
たとえばスピーカー音量をつかさどるオブジェクトの値を100に変更しようとします。Delegateに「音量を100にしたいんだけど」とメッセージを送ると、Delegateが「ヘッドホン端子になにか接続されてるから、今は音量0のままにしておきます」と答えてくれたりします。Delegateがいない状況だと、ヘッドホン端子のチェックをする、という余計な手間を自分でやらないといけません。
Target-Action
MVCのView部分はボタンやスライダーといったユーザーからの入力を受け付けるオブジェクトでも良いわけなのですが、それが押されたというようなメッセージ（action）があった場合、それを適切に処理できる別オブジェクト（target）にわたしてやる必要があります。それがTarget-Actionという仕組みです。
「OK」だったり「Cancel」だったり、ボタンごとに機能が違いますから、それぞれのボタンからのactionメッセージが適切なtargetに送られるようにしてあげないといけません。
