iOS：デリゲート/データソース（プロトコル）とプロパティを使用する場合

Question

多くのCocoaPodとネイティブiOSライブラリでは、セットアップやカスタマイズを行う手段としてまたはCustomClassDataSourceのいずれかのプロトコルを使用しています。私は、このプログラミングモデルをいつ使うべきかと思っていました。なぜなら、これで多くのことをプロパティで達成できるように思えるからです。

例

私はSmurfLabelを持ってSmurfViewControllerというカスタムクラスを定義する場合、私有財産としてsmurfLabelを格納し、このようになりますsmurfと呼ばれる公共計算性質を持つためのより良い習慣です：

private var smurfLabel = UILabel() 
public var smurf: String { 
    get { 
    return smurfLabel.text 
    } 
    set(text) { 
    smurfLabel.text = text 
    } 
} 

かは、私はこのようになります公共の機能を持っているSmurfDataSourceを定義する必要があります。

func textForSmurfLabel() -> String { 
    return "smurfText" 
} 

ここで何を使用すればよいですか？

Answer 1

プロパティを使用するだけです。代理人とデータソースは、コントローラ/オブジェクトをnavigationStack /ビュー階層からインスタンス化する代わりに、別のコントローラ/オブジェクトが互いに話すことができます。デリゲートは、2人の間の特定のコミュニケーションを形成し、その関係がどのように分離されているかを明確に知ることができます（あなたがそれをそのまま維持しようとしていると仮定します）。コールバックが「より良い」と言う記事には同意しない。彼らは驚くべきことですが、私はそれらを頻繁に使用することをお勧めしますが、迅速な選択肢のほうが最良の場所を提供していることを理解してください。

私は少しバイアスかもしれませんが、スウィフトはOOPがバックボーンとそれがうまくあなたに自分自身を見つけるそれぞれの状況に正しいツールを提供するために一緒に入れたたすべてのものを持つ素晴らしい言語です。

Iしばしば多くの子コントローラを管理するViewControllerを監督している私のより高度なセットアップでは、これらのツールと他のカスタマイズ可能なオプションの両方を使用して自分自身を見つけてください。それはアクティブであるすべてのものに直接アクセスできますが、その子どものいずれかがそれと通信する場合は、代議員を通じて行われます。その主な仕事は、画面上の自分の場所を処理することです、私はすべてを管理し続ける。

Answer 2

代理人とデータソースは、ビヘイビアを単純な値ではなく他のエンティティにオフロードするためにより適しています。言い換えれば、あなたの型が何かの値を必要とするだけであれば、それをクライアントコードから設定できるプロパティとして公開する方が合理的です。

しかし、ユーザーが特定のテーブルビューのセルをタップすると、UITableViewにハードコードするべきではない動作が発生します。代わりに、フレキシビリティのために、その振る舞いの実装をデリゲートで作成し、必要に応じてUITableViewによって呼び出すことができます。

一般的に、サブクラス化を不要にする方法として、委任を考えてください。通常、サブクラスでオーバーライドするメソッドは、基本型のサブクラスではなくANY型で実装できるプロトコルに移動されるためです。そして、内部的に実装されたメソッドを呼び出して特定のビヘイビアを取得するのではなく、外部の共同作業クラス（デリゲート）でビヘイビアを呼び出すだけです。

データソースまたはデリゲートを使用するときの最良のガイドラインは、「今後この値や動作を変更するには、このクラスをサブクラス化する必要がありますか」という質問です。答えがいいえの場合は、クライアントコードからプロパティを設定するだけで済みますので、委譲は使用しないでください。答えが「はい」の場合、将来のプログラマーにクラスをサブクラス化してユースケースに対応させるのではなく、その動作をデリゲートまたはデータソースにオフロードします。

Answer 3

委任は未定義アクティビティのインターフェイスです。 SDKやフレームワークを作成するときには、ユーザーがインターフェイスの期待活動の適切なコードを書くことができるように、インターフェイスを提供する必要があります。

つまり、Table Viewにはコンテンツを表示するためのデータソースが必要ですが、リンゴのライブラリ開発者は、そのライブラリユーザが使用するコンテンツが何であってもコンテンツを認識しません。彼らはデータソース、デリゲートのようなインターフェイスを提供しました。 とライブラリでは、これらのメソッドを呼び出すだけです。それが図書館の作成方法です。

あなたのコードでは、ラベルは非常に明示的に定義されているだけでなく、現在のビューにも含まれているため、定義されていないアクティビティに対してインターフェイスを作成する必要はありません。

この種のコーディングスタイルについて詳しく知りたい場合は、ソフトウェアデザインパターンに関するいくつかの調査を行う必要があります。

https://en.wikipedia.org/wiki/Observer_pattern

https://en.wikipedia.org/wiki/Delegation_pattern

https://en.wikipedia.org/wiki/Software_design_pattern

、彼らは非常に適切に必要なすべてのデザインパターンを使用するので、私は、非常に多くのAppleのSDKが大好きです。