UIViewController。新規クラスのテンプレートにも含まれていますね。扱うのに必要な2つのプロトコルに適合しています。クラスだけで事足りてしまいます。便利なクラスである反面、複雑な処理をしようとすると、どんどん肥大化してしまうという欠点もあります。次の3つのクラス/プロトコルの役割を1クラスで担っている点が考えられます。あるたくさんのフィールドやメソッドは、それぞれが上記3つのうちどの役割のために必要なものなのか、だんだんわかりにくくなってきてしまいます。実装を共有したい場合にも、1つのクラスにすべて収まっていると何かと都合の悪い点が出てきたりもします。組み合わせて使うということをよくやるようになりました。関連の処理を分離したような実装にするパターンを何度か使っています。このように役割を分担することで、個々のクラスはよりシンプルになります。用の処理かの判別を不要にする、というような設計も可能になります。いうだけではないという点です。ドキュメントにありますが、たとえば次のような機能を持っています。初回の画面表示時にセルのリロードと選択のクリア処理が入る。画面表示後に、スクロールバーを点滅させる。編集状態を連動させる。使わない場合、必要に応じてこれらの機能を自分で実装する必要があります(簡単です)。分離してみたら思った通りに動かない場合はそのあたりを確認してみてください。2つに適合したクラスの一般的な呼び方です。良いものが思いつかず、何とかひねり出したクラス名をつけていますが、今もこの文章を書きながら「いい名前ないかなぁ」と考えてしまっています。