MVVM实现UICollectionView的方法-第4部分
单元中的用户交互。
如果您对示例项目感兴趣，那么PowerTools是一个小框架，我正在构建这些框架，应用这些文章中介绍的所有策略，然后在您的计算机上进行尝试，只需在bash终端上尝试PowerTools 。
在这里您可以找到以前的部分：
- 第1部分-使您的内容独立
- 第2部分-增强ViewModel和单元的可重用性
- 第3部分-使用UICollectionFlowLayout的单元格大小
互动，滚动和委派
正如我们在第3部分中所看到的，UICollectionViewDelegate与UICollectionViewDataSource一起埋在我们的DataSource类中。 这是因为UICollectionViewDelegate具有很多功能：
- 定义单元格的大小
- 响应用户与单元的交互
- 是UICollectionView的UIScrollViewDelegate 吗？
但是通常我想分别定义和管理那些行为，以遵守单一责任原则。 为此，我应用了Jesse Squires在本文中描述的技术，在数据源上定义了两个委托：InteractionDelegate和UIScrollViewDelegate。 所有这些方法都将代理给委托，可以单独实现这些委托并将行为注入到DataSource中。
我的假设是：ViewController，您将在迭代呈现的业务资源上呈现劣势。 如果为真，则每个项目都有一个要呈现的特定UIViewController或定义该项目需要呈现哪个UIViewController的相关逻辑。
同时， UIViewControllers需要定义上下文，通常这些信息不依赖业务资源，而是直接从UIViewController到UIViewController 。
基于这些假设，我可以定义一个Builder，他是唯一知道如何构造目标UIViewController的Builder 。 它将包含与构建UIViewController所需的业务资源相关的所有信息，并从工厂接收要注入的上下文。
我定义了在应用程序级别在PowerTools框架中通用的Context ，通常将其用于依赖注入。 Factory是一个协议，因此可以从需要它的每个对象中实现它，并将上下文注入到Builder中，因此一切都是类型安全的。
观看AbstractFactory的实现，我们可以看到一个新的接口，该接口以前从未知道过，但是它的名称应该很清楚： BuilderContainer。 这是启用类型擦除的层：
类型擦除是一个复杂的论点，如果您有兴趣深入了解，建议您从NatashaTheRobot的本文开始。
FastForward，这是我在ItemViewModels中应用typeErasure的方式：
此代码段中的重要部分是ColorItemViewModel扩展，其余的仅用于提供有关正在应用的内容的上下文。
因此，现在我们只需要将Interaction委托绑定到AbstractFactory即可使其像黑魔法一样工作，并且要做到这一点，使用条件扩展的解决方案非常简单：
结论
我大量使用这些模式来增强应用程序中的代码可重用性和责任封装，因此，如果您发现此提示很方便或有增强的想法，请提示我或向PowerTools提出拉取请求