objective-c - クラスを宣言し、同じ名前のプロトコルを宣言するとはどういうことですか?

Question

NSObject クラスには NSObject プロトコルがあります。

ポイントは何ですか？

これは、多重継承をエミュレートする何らかの方法ですか?

これは何のパターンですか？

score 7 · Accepted Answer

いいえ、それだけです：

Foundation フレームワークは非常に人気がありNSObject、ルートクラスに関してはこの分野を支配しています。
そのため、人々はその名前と、それが実装するメッセージとメソッドに慣れています。たとえば、Objective-C の開発者は通常、クラスが+ allocandを実装することを期待し- initていますが、これはたまたま一般的な規則であり、クラスが必ずしもそうするとは限りません。
しかし、が階層のルートクラスでNSObjectはないNSProxy場合 (たとえば、について考えてみてください)、NSObject実装されているすべてのメッセージに応答させると便利なので、まったく異なる新しい名前と規則のセットを学ぶ必要はありません。
そのため、Apple は、これらの一般的なメソッドをと呼ばれる別のプロトコルに抽出することを選択しました。このプロトコルはNSObject、NSObjectクラスが実装します。これは、正常なルートクラスで実行されます。

したがって、基本的には、利便性とコードの読みやすさのためです:)

score 3 · Accepted Answer

主な（実用的/外見上の）理由と、多くのアップルヘッダーに見られるものは他のプロトコルです。

プロトコルは通常、NSObject から「派生」しません。つまり、特定のプロトコルに準拠するデリゲートとデータソースは、もはや NSObject ではないようです。

@protocol TableDelegate  
...
@end

id<TableDelegate> delegate = bla;

==> デリゲートは、基本的な NSObject メソッドに応答していないようです。NSObject として定義する必要がありますが、定義にクラスとプロトコルを混在させるのは気分が悪いです。

SO @protocol を NSObject にします! そのためには、NSObject プロトコルが必要です。

@protocol TableDelegate<NSObject>  
...
@end

id<TableDelegate> delegate = bla;

===>デリゲートはNSObjectに準拠し、すべてがより自然に感じられます

それはまた、「インターフェースに向かって設計する」という考えに似ています。

2 に答える 2