私の理解では、プロトコルは他の言語のインターフェイスのようなものであり、期待されるメソッドを宣言しますが、カテゴリを使用すると、新しいメソッドを既存の型に追加できます (おそらく、所有していない型も含まれます)。
では、なぜ iPhone SDK はデリゲート型の宣言にカテゴリを使用することがあるのでしょうか? 通常、すべてのデリゲートが id<MyDelegateProtocol> と入力されることを期待しますが、そうでない例がたくさんあります。
たとえば、NSURLConnection を参照してください。そのデリゲートは「id」と入力され、「コントラクト」は NSObject (NSURLConnectionDelegate) のカテゴリとして宣言されます。
では、これらの場合にカテゴリを使用する動機は何ですか?
Objective-C 2.0 では @optional プロトコル ディレクティブが導入され、特定のプロトコル メソッドをオプションとして宣言できるようになりました。Obj-C 2.0 より前は、オプションのデリゲート メソッドを許可するためにカテゴリが使用されていました (具体的には、非公式プロトコルと呼ばれる NSObject のカテゴリ)。
私の推測では、iPhone SDK でのプロトコルではなくカテゴリの使用のほとんどは、同等の Mac クラスからの持ち越しです。たとえばNSURLConnection、Mac SDK と iPhone SDK の両方に存在するため、コードは共有されている可能性があります。Apple はまだ正式なプロトコルを使用するようにすべての Mac クラスを変更していないため、多少の矛盾が残っています。
「Objective-C 2.0」と呼ばれる、OS X 10.5 と iPhone SDK で展開された Objective-C の改訂までは、カテゴリを使用してオプションのプロトコルを作成することしかできませんでした。Objective-C 2.0 では、新しい @optional キーワードがプロトコルに追加され、どのメソッドがオプションであるかをマークしました (残りは暗黙的に必須です)。
したがって、@optional キーワードが登場する前の時代からのわずかな持ち越しだと思います。
編集:元の質問に表示されたフォローアップに答えるには: 非公式プロトコルの NSObject/id でカテゴリを使用する動機の一部は、オブジェクトがデータソース (またはデリゲートなど) で呼び出す可能性のあるメソッドを文書化し、グループ化することです。 、およびコンパイラが知らないメソッドを呼び出しているというコンパイラの警告を回避する程度は低くなりますが、呼び出しを受け取るオブジェクトに存在します。これらのデータソース メソッドを呼び出すクラスを実装するクラスを想像してみてください。おそらく、my を呼び出すことに関心がある場合はいつでも [obj RespondsToSelector: @selector(my:datasource:method:)] を使用して、メソッドが存在することを確認する必要があります。 :datasource:method: オブジェクト obj のメソッド。
これは、「オプションのプロトコル メソッド」を持たない object-c 1.0 からの遺産です。