何かが欠けていない限り、どの .h ファイルにプロトコル定義を入れるかは恣意的なようです。それが独自の .h ファイルにあるかどうかさえ疑問に思っています...(Javaでは、独自のファイルにあります)
6 に答える
プロトコルの配置は、使用方法によって異なると思います。多くの場合、プロトコルは別のクラスのデリゲートまたはデータ ソースの機能を定義するために使用されます。その場合、プロトコル定義を他のクラスの先頭に安全に置くことができると思います-それらは一緒に使用されることがバインドされているためです。
共有基本クラスの代わりにプロトコルを定義している場合は、おそらく別のファイルに配置する必要があります。たとえば、「操作」プロトコルを実装するいくつかの異なるクラスがあります。私の他の関数のいくつかは、プロトコルを実装するオブジェクトを受け取ることを期待しており、実際のクラスについてはあまり気にしません。その場合、プロトコル定義を独自のヘッダー ファイルに配置して、独自にインクルードできるようにするのが理にかなっています。
ただし、ベニーは正しいです-どこに配置しても技術的に定義されます(使用する前にどこかに含まれている限り)。
プロトコルは通常、独自の .h ファイルで定義されます (私の経験では)。ただし、それらは shared.h ファイルで定義できます。プロトコルのユーザーが共有ファイル配置でプロトコルを採用できるようにすることは困難であり、さらに、API が乱雑になります。プロトコルが独自の .h ファイルにある場合、ドキュメントと使用法はおそらく簡単になります。
また、他のクラス宣言を含む .h ファイルの代わりにプロトコル .h ファイルをインクルードするだけでよい場合、ポリモーフィック実装などにプロトコルを使用すると、オーバーヘッドが少なくなります。このアイデアの正確なコスト/節約についてはわかりませんが、いくつかの(より小さなバイナリ?)
よろしく、フランク
どこかで定義され、コンパイルしているファイルの1つに含まれている限り、定義されていると思います。Java にあるように、Objective-C には「ClassName.java」のような規則はありません。
これは、プライベート メソッド/プロパティなどのカテゴリなどを実行する場合に非常に役立ちます。
これは、Objective-C のスタイルの問題です。本当に「適切な」方法は、プロトコル用に別の .h ファイルを作成することだと思います。他のものに属さないプロトコル (たとえば NSCoding など) を作成する場合、それがまさに私が行うことです。一方、プロトコル (または NSObject のカテゴリを使用して非公式のプロトコル) を作成する場合、ほとんどの場合、NSTableView のデータ ソースの非公式のプロトコルなど、別のクラスに結び付けられます。これらの状況では、簡単にするために、そのクラスのヘッダー ファイルに宣言を入れただけです。
Objective-C でも同じです。プロトコルは、クラス間で共有されるメソッドのリストであるためです。プロトコルは、対応する実装のないメソッドのリストにすぎません。それらは、他の誰かによって実装されることを意図しています。