UITableViewCell的装饰器模式

Question

我想知道是否有人曾经尝试或考虑过使用装饰器模式来使UITableView代码更容易枯竭。

我正在考虑的是为UITableViewCells创建一组可重用的装饰器，例如，一个用于添加背景渐变的装饰器，一个用于添加不同阴影的装饰器，以及各种其他样式。

然后，您将能够将装饰器链接在一起，以获得所需的效果，而不是每次想要重用相似的设计样式时，都必须将一些Frankenstein代码添加到不同的对象上。

这有意义吗，或者我只是在重新创造轮子？我真的不喜欢将UITableViewCells子类化，并且认为这将是解决这个问题的一个好方法。

我很乐意听到你们中的一些人的意见，他们在这个话题上比我有更多的Objective-C和UIKit经验。

Answer 1

装饰器模式不是典型地基于抽象库或根部的接口/协议吗？因为这里的库是不可交换的(它必须是一个UITableViewCell)，所以这可能很棘手。

也许你可以通过代理来实现它，也就是通过子类化NSProxy来包装一个UITableViewCell。我不知道这是否会起作用，因为UIKit类往往彼此紧密集成。代理和实际单元格将具有不同的身份，如果单元格以self作为参数向表视图发送消息，这可能会混淆表视图。

另一种选择是将表视图单元格子类化一次，以添加某种可扩展的委托机制，这样您就可以动态地向每个单元格添加委托。我称它们为委托，因为它们不会从表格单元格子类中继承，只是为它添加一个行为。然后，您将截获发往单元格的消息，并根据对象中存在的委托动态决定是由委托接收消息还是直接转到超类(UITableViewCell)方法实现。您可以为每个委托定义一个协议，该协议声明这样扩展的单元将接受的新方法/属性。

首先，我不知道实现它会有多大的麻烦，也不知道每个委托的代码会有多复杂。我想你必须试一试，看看它在实践中是否值得。

在任何情况下，将行为混合到UIKit类中肯定是一件有趣和有用的事情。对于我自己的应用程序，我已经构建了一个自动视图布局系统，它根据视图的内容、可用空间和某些大小调整参数来布局视图。这样做可能会在一定程度上减少系统中的重复代码量。

Answer 2

虽然从体系结构的角度来看，这种方法是合理的，但在iOS的现实中，它对性能有一个可怕的影响(以前也曾尝试过，但结果并不好)。iOS尽可能多地缓存预先呈现的表视图单元格，因此以UIKit设计者没有预料到的方式执行不同单元格的布局和外观的运行时修改将破坏缓存，并且性能将受到影响。

看看Matt Gallagher handles custom cell drawing，他的方法在今年的全球开发者大会上被苹果公司伪装成了福气。此外，请观看“提高响应性的提示和技巧”和“理解UIKit渲染”sessions from WWDC，因为它们解决了提高UITableView性能的实际技术。