Objective-C では、通常、次のように定義された動的に型指定されたオブジェクトを返すメソッドを目にします。
- (id)someMethod:(id)someParameter;
ただし、これもできることはわかっています。
- someMethod:someParameter;
興味深いことに、よりコアレベルの基礎クラスでは後者の規則を目にしますが、他の誰もが最初の規則を使用しているようです。Objective-C ランタイムは、型指定されていないメソッドまたはパラメーターが を返すと推測するためid、なぜそれを含める必要があるのでしょうか? 読書の流れを壊していませんか？
開発者がこの規則を使用することで起こりうる問題について考えていることを知りたいだけでなく、それが単に奇妙だと思うかどうかも知りたいですか?
言語は両方の形式を許可するため、実際にはスタイルの問題です。-(id)someMethodそれを考えると、Objective-C は簡潔さよりも読みやすさに大きく依存しており、ほとんどの開発者は戻り値の型を明示的にするため、最初の ( ) を好むでしょう。
あなたの質問には直接関係ありませんが、id動的に型付けされていません。これは、Objective-C オブジェクトへのポインターです。Objective-C ではメッセージ ディスパッチは動的であるため、id多くの場合、動的型のように扱うことができますが、実際には静的型です。つまり、Objective-C は動的にバインドされていますが、静的に型付けされています。
まず、ランタイムではなく、型を推測するのはコンパイラだと思います。
2 番目の規則は、Objective-C の深いオブジェクト指向性から来ていると思います。ほとんどのコードはオブジェクトを扱うことを意図しているため、デフォルトの戻り値の型と引数の型はidです。これの便利さは、オブジェクトで使用するメソッドがどこかに存在する限り、オブジェクトの特定の型を宣言してもコンパイラが気にしないことです。
最大の潜在的な問題は、別の種類のオブジェクトであると誤って認識したために、応答しないオブジェクトにメッセージを送信することです。これが、タイプを除外するべきではなく、代わりに可能な限り具体的なタイプを使用するべきである理由です。
2 番目の規則は、アプリケーションを作成するときにほとんどの場合に遭遇する特定のオブジェクトやクラスではなく、言語とランタイムの多くの動的機能を使用して柔軟性を重視するコードにのみ適していると思います。適切な場所で最初の規則を使用すると、読みやすさが向上し、間違いを犯しにくくなります。これはセマンティクスの問題です。型をできるだけ具体的にすると、誤解の可能性がなくなり、全体的により良いコードを書くのに役立ちます。
多くの NeXT 時代のコードは、戻り値の型を除外するというこの規則に従って(id)おり、そのコードのほとんどは OS X に引き継がれました。コードが型を除外すると混乱し、4 ～ 5 文字を節約することは最近ではまったく無意味です。とりあえず。私の推測では、古い習慣はなかなか消えません — 私の経験では、常に戻り値の型を含めるのがベスト プラクティスです。確かに、言語の初心者にとって物事がより明確になり、仮定が少なくなります。