私は、各実装がユーザーインターフェイスの一部をカスタマイズできるようにするアプリケーションフレームワークの設計を任されています。そのような例の1つは、実装（これをクライアントと呼びましょう）が、特定の画面に返すコレクションビューセルを定義できることです。フレームワークは、適切なオブジェクトを販売してアプリを簡単に構築できるようにするだけです。これは、いくつかの類似したインスタンスを構築するためです。
フレームワークへの私の現在のアプローチは、アプリ全体のすべてのプレゼンテーションおよび却下イベントを担当する調整コントローラーを設計することでした。デフォルトのCoordination Controllerは、フレームワーク内のすべてのデフォルトのビューコントローラーを提供します。デフォルトのビューコントローラーは、構成されたUIを提供することなく、関連するタスクをすべて実行します。たとえば、1つのコントローラーがテンプレートセルを含むコレクションビューを表示し、特別なものは何もありません。この設計の利点は、コントローラー間の結合がなくなり、クライアントがデフォルトのコーディネーターをオーバーライドして、特定のタスクに対してまったく新しいビューコントローラーを返すことができることです。
私が抱えている問題は、このフレームワークを設計して、クライアントが独自のカスタムUIをアプリに追加できるようにする方法です。
アプローチ1
フレームワークにビューファクトリを必要とし、このビューファクトリがすべての関連するビューの販売を担当するようにします。したがって、アプリデリゲートでは、クライアントがたとえばCollectionViewCellFactoryを作成し、インターフェイスが、準拠するクラスが提供する必要のあるすべてのセルを定義するように強制できます。私はこのデザインのコードベースを継承しましたが、コードベースが抽象化されすぎてカスタマイズできなかったので、コードベースから離れました。これには、アプリのあらゆる側面に対応する多数のファクトリーが付属しており、これにより、すべてのアプリのセットアップ時間に数日が追加されました。
アプローチ2
各ビューコントローラーは、これらのカスタムUIクラスを実行時に定義できるようにするサブクラス化フックまたはセットアップAPIを指定します（UISplitViewControllerが呼び出し側がviewControllersプロパティを使用してコントローラーをセットアップする方法と同様です）。これを行うには、各クライアントは基本の調整コントローラーと各コントローラープレゼンテーションでサブクラス化するだけです。コントローラに適切な値を設定して、目的のUIを実現します。何かのようなもの
viewController.registerReusableCellsBlock = ^(UICollectionView *collectionView){
//perform custom registration
}
viewController.cellDequeueBlock = ^UICollectionViewCell<SomeProtocol> *(UICollectionView *collectionView,NSIndexPath *indexPath){
//dequeue custom cells
}
現在、私は再利用性を促進し、ViewControllerの肥大化を防ぐために、ビューのデータソースを別のオブジェクトに分離しています。これにより、セルのインターフェイスを提供するビューコントローラーのサブクラス化が少し難しくなりますが、不可能ではありません。
アプローチ3
おそらく、フレームワークを設計してその使用法を予測しようとするのは悪い考えです。おそらく、最良のオプションは、セットアップコストが比較的高い場合でも、最大限の制御でサブクラス化できるようにすることです。次に、いくつかのクライアント用に構築したら、出現するパターンに気づき、ルートに沿って最適化を開始します。
私はフレームワークの内部でカスタマイズ可能にする方法を理解しています。私が苦労しているのは、クライアントによるフレームワークの潜在的なカスタマイズポイントを定義するインターフェースを最適に定義する方法です。
TL; DR
インターフェイスの最も複雑な部分は、コレクションビューセル内にネストされたコレクションビューを扱います。これにより、セルの水平ページングと垂直スクロールが可能になります。これは、水平セルを管理し、各セルのコレクションビューを新しいデータソースで構成する1つのデータソースを持つことで実現されます。
これらすべてのセルをカスタマイズ可能にするインターフェイスをどのように設計しますか？