0
私は雑誌ビューア用のAPIインターフェイスを設計しています。 iGizmoのようなもの（iPad用）。雑誌を表示するビューは、TableViewと非常によく似ています。記事はセクションやページをセルと考えることができるため、UITableViewDataSourceの設計の根拠
そのため、私はDataSource &のデリゲートをUITableViewと同じ方法で公開したいと思います。しかし、私は完全にアップルがTableViewデリゲート/ DataSourceを設計した理由はそれが常に各メソッドのパラメータとしてTableViewを提供する方法ではない。
私はそれを合理化しようとしましたが、私はそのようなAPIデザインのための良い言い訳を見つけませんでした。 tableView/magazineViewパラメータをAPIに残すことを考えています。
このようなAPI設計の背後にある理由はありますか？
以下のようなメソッドを書くのが簡単ではないでしょうか？
– cellForRowAtIndexPath:
– numberOfSections
– numberOfRowsInSection:
– sectionIndexTitles
– sectionForSectionIndexTitle:atIndex:
– titleForHeaderInSection:
– titleForFooterInSection:
データソースは多くのビューに対してコンテンツを提供し、デリゲートは多くのビューのデリゲートになる可能性があります。さらに、場合によっては、デリゲートまたはデータソースが、どのように応答するかを決定するためにビューを呼び出すビューを検査する必要がある場合があります。 – Jonah
@Jonah、@middaparka、私は同意しますが、これまでに、1つのインスタンスが複数のテーブルビューを提供していたような方法でデータソースを実装しましたか？同じデータソースクラスの2つのインスタンスを作成しないでください。このようなAPI設計は、objcがOO言語であるという事実を無視しているようです。 –
モデルの特定のビューを提供するためにデータソースを作成し、そのデータソースインスタンスを再利用して、複数のビュー、異なるビューのビューを異なる方向に戻すことができますが、データソースは通常考慮する必要はありませんデータを要求するオブジェクト一方、私の代理人は、自分の呼び出し元のアイデンティティを常にチェックしています。例えば、NSURLConnectionsの集合を、集合的なデリゲートとして機能する単一のクラスを使用して管理することができます。 – Jonah