面向协议的UITableViewCells

这篇博客文章展示了如何通过使用面向协议的编程 （POP）作为子类化或组合的更好替代方法来实现一组UITableViewCell变体。 准备？ 我们走吧！

给我看看细胞！

在构建我的Cast Player应用程序时，我需要添加几个设置页面，以允许用户在应用程序中进行一些调整，并包括指向“发送​​反馈”表单和一些“关于”屏幕的链接。 这是最终结果：

从上面的屏幕中，我们可以识别六种不同类型的单元格：

总体而言，这些细胞具有以下特征（或行为）：

• 单元格突出显示
• 显示标题
• 显示人类可读的字节数

我们如何去建立一组能很好地代表这六个细胞变异的类呢？ 第一步是列出网格中的所有单元格类型和所需特征：

从上表可以看出：

• 所有细胞都没有采用这些特性。
• 一些特征是某些细胞所必需的，而其他细胞则不需要。

这意味着构建UITableViewCell类层次结构在这里无法正常工作。 实际上，这些单元格类型都不是基础类的理想选择。 该怎么办？ 🤔

协议和扩展！ 好极了！

幸运的是，这篇关于Swift 2.0中Mixins和Traits的精彩文章可以为我们指明正确的方向。 直观地讲，协议和扩展对于该用例确实可以很好地工作，但是如何在此处正确使用它们呢？

这个想法是我们可以使用协议为每个特征定义接口 ，并提供带有扩展的默认实现 。 然后，我们可以创建非常小的UITableViewCell子类，并使它们仅符合所需的协议。 在另一个名为“面向协议的MVVM简介”的精彩演讲中，探讨了一个非常类似的问题。 让我们看看它是如何工作的！

有了协议和扩展，我们可以编写第一个特征TitlePresentable ：

在代码中，这表示为：

注意 ： HighlightableTableViewCell是通过子类实现的唯一特征，并且可以用作三种其他单元格类型的基类。 一旦为给定类型选择了基类，则只能通过协议扩展来添加其他特征。

结论

使用Swift协议和扩展作为增加行为（特征）的一种方式，可以在我们的类的设计中取得重大胜利，并有助于保持层次结构的平坦。 🚀主要优点：

• class媚的阶层阶层
• 生成的API /类可以更轻松地扩展
• 与添加和删除代码相比，添加和删除协议一致性更容易
• 减少代码重复

欢迎反馈

这篇文章中介绍的解决方案对我和我的特定用例都非常有效-我希望这个实际示例可以帮助我比起初时更好地理解如何使用协议扩展。 如果您知道这样做的更好方法，请在评论中告诉我！

注意 ：这篇文章首次出现 在 2016年6月18日发布的 此博客文章 上。

有关更多此类故事，请 订阅我的邮件列表 。

如果您喜欢，请单击下面的so，以便其他人在中此看到此内容。

并且不要忘记查看我的 Cast Player应用程序 。 😇