objective-c - Objective Cで@protocolsを使用する主な理由は何ですか？

Question

サブクラスを作成してメソッドを継承するのではなく、プロトコルを使用したいのはなぜですか。

私にそれを説明してください、私はこのトピックについて混乱しています、私は読んでいる本の説明にあまり満足していません。

メソッドを取得するために、他の方法の代わりにプロトコルをどこで使用しますか？クラスをサブクラス化してメソッドを取得できる場合、メソッドを定義する必要があるプロトコルを使用するのはなぜですか？

Answer 1

サブクラスを作成してメソッドを継承するのではなく、プロトコルを使用したいのはなぜですか。

プロトコルにより、無関係のクラスがすべて同じインターフェイスを実装できるようになります。これらの各クラスのインスタンスは、プロトコルのクライアントが使用できます。たとえば、UITableViewDataSourceは、プロトコルを実装する任意のオブジェクトからテーブルがデータを要求できるインターフェイスを提供するプロトコルです。テーブルビューは、データソースインターフェイスを実装している限り、オブジェクトのタイプを気にしません。

すべてのテーブルデータソースが共通のクラスから継承する必要があるとしたら、どれほど不快なことになるか想像してみてください。Objective-Cは単一の継承のみを提供するため、データソースに単一の種類のオブジェクトのみを使用するように効果的に制限されます。ただし、プロトコルを使用すると、データソースはビューコントローラ、モデルオブジェクト、または場合によってはリモートオブジェクトになります。

より具体的には、プロトコルはポリモーフィズムの形式を許可します。つまり、単一のオブジェクトは、ビューコントローラ、テーブルデータソース、テーブルデリゲート、スクロールビューデリゲートなどの複数の形式をとることができます。Objective-Cは単一継承言語であるため、継承を介してこれらのインターフェイスの1つのみを取得します。残りは自分で実装しますが、他のオブジェクトの動作をカスタマイズするために特定のプロトコルを採用するのが一般的であるため、多くの場合、それは理にかなっています。

Answer 2

サブクラス化とプロトコルは2つの異なるものだからです。サブクラス化は、特定のクラスの以前のすべての機能を継承しながら、新しい機能でクラスを拡張しますが、プロトコルをクラスに適用すると、クラスに機能が追加されるだけで、クラスから何も継承されません。そのクラスが通常何であるかは重要ではありません。

プロトコルは、Objective-Cのデリゲートパターンで最も頻繁に使用されます。これにより、オブジェクトは、そのオブジェクトが何であるか（つまり、クラス）を気にせずに、別のオブジェクトにメッセージを送信できます。

多くの場合、デリゲートは次のように宣言されます。

 @property(nonatomic, assign) id < MyObjectDelegate > delegate;

プロパティのクラスはid-本質的に、オブジェクトが車であるかカメであるかは関係ありません-知っておく必要があるのは、それがオブジェクト（id）であり、契約上関数にサブスクライブしていることだけです。あなたはそれが必要です。したがって、デリゲートがタイプturtleの場合は、[delegatemyStateChanged]を呼び出すことができます。または、デリゲートが車の場合は、[delegatemyStateChanged]を呼び出すことができます。あなたが知る必要があるのは、あなたがそれにメッセージを送るならば、それがそれを受け入れるということだけです。

私はObjective-Cデリゲートの使用について調べて読みます。これは、プロトコルをよりよく理解するのに本当に役立ち、サブクラス化とどのように違うのかを理解するのに役立つと思います。他のオブジェクト指向プログラミング言語に精通しているかどうかはわかりませんが、精通している場合、プロトコルは他の言語のインターフェイスに最も似ています。

Answer 3

プロトコルは多くのプロトコルを実装できるので便利ですが、代わりに単一のクラスしか拡張できません。