我的任务是设计一个应用程序框架，该框架将允许每个实现自定义用户界面的各个部分。一个这样的例子就是实现（现在称它为客户端）可以定义要返回到特定屏幕的集合视图单元格。该框架仅负责出售适当的对象，以使构建应用程序变得更加容易，因为我们将构建一些外观相似的实例。
我目前对框架的方法是设计一个协调控制器，该控制器负责整个App中的所有演示和解雇事件。默认的Coordination Controller售卖框架内所有默认视图控制器，它们全部执行其相关任务，而不必提供配置的UI。例如：一个控制器将显示一个包含模板单元格的集合视图，没有什么特别的。这种设计的好处在于，它消除了控制器之间的耦合，还允许客户端覆盖默认的协调器，并为特定任务返回全新的视图控制器。
我遇到的问题是如何设计该框架，以允许客户端将自己的自定义UI添加到App中。
方法一
使框架需要一个视图工厂，并让该视图工厂负责出售所有相关视图。因此，在App Delegate中，我们可能会强制客户端创建一个CollectionViewCellFactory例如，并且该接口定义了任何符合类需要提供的所有单元。我继承了这种设计的代码库，并因为它过于抽象和可定制，而放弃了它。它为App的各个方面提供了大量的工厂，这为每个App的建立时间增加了几天的时间。
方法二
每个视图控制器都指定子类挂钩或设置API，以允许在运行时定义这些自定义UI类（类似于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
界面最复杂的部分涉及嵌套在“集合视图”单元格内的“集合视图”。这允许单元的水平分页和垂直滚动。这可以通过拥有一个管理水平单元格并使用新数据源配置每个单元格的收集视图的数据源来实现。
如何设计一个允许所有这些单元都可自定义的接口？