UIPickerViewデータソースxデリゲートデザイン

Question

UIPickerViewDelegateには、データ（タイトル）を認識する必要があるメソッドが含まれているという、実際には奇妙な、または悪いデザインの決定が見つかりました。それはその全体の目的となるのでDataSourceです。これらのように：

pickerView(_:titleForRow:forComponent:) 
pickerView(_:attributedTitleForRow:forComponent:) 
pickerView(_:viewForRow:forComponent:reusingView:) 

私はDataSourceとDelegateのために異なるオブジェクトでPickerViewを実装したいです。もちろん、新しいデリゲートを作成するのは簡単です（おそらくPickerViewListenerDelegate）。しかし、リンゴがこのデザインの決定を下したので、最初に議論する価値があると思いました。

この奇妙なデザインの決定のポイントは何ですか？私はここに何かを逃していますか

Answer 1

UIPickerViewDataSourceプロトコルは、データソースの直接的な特性、すなわち、それらの各々における成分の数および行の数だけを扱う。

UIPickerViewDelegateプロトコルがプレゼンテーションに対応します。サイズ、タイトルまたはビュー、および選択変更のコールバックを提供します。

これをUITableViewDataSourceとUITableViewDelegateと比較すると、奇妙なパターンがかなり異なっています。

多くの場合、delegateとdataSourceの両方が、コールを基になるモデルにルーティングして必要なUI要素を構築する同じオブジェクト、つまりビューコントローラに配線されます。個人的には、dataSourceをデータモデルに配線するのはコントローラーの代理人だから、カプセル化を簡単に破ることができる奇妙な決定をすると思います。

つまり、基本的には、指定されたパターンを使用してモデルとプレゼンテーション（つまりフォーマッタ）を分離することができます。それが役に立つと思ったら、あなた次第です。