UITableViewCell的装饰模式

Question

我想知道是否有人试图或想过使用装饰器模式来更容易干掉UITableView代码。

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

然后，您可以将装饰器链接在一起，以获得所需的效果，而不必每次想要重用类似的设计样式时将一些Frankenstein代码固定到不同的对象上。

这是否有意义，或者我只是在重新创建方向盘？我真的不喜欢继承UITableViewCells，并认为这是解决这个问题的好方法。

我很想听听你们中有些人的观点，他们比我在这个主题上有更多的Objective-C和UIKit经验。

Answer 1

装饰器模式通常不是基于抽象基础或根目录下的接口/协议吗？由于你的基地不可交换（它必须是UITableViewCell），这可能很棘手。

也许你可以通过代理来完成它，即子类化NSProxy来包装UITableViewCell。我不知道这是否有效，因为UIKit类往往彼此紧密集成。代理和真实单元将具有不同的标识，如果单元以self作为参数向表视图发送消息，则可能会混淆表视图。

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

我不知道首先要实现多少麻烦，以及每个代表的代码有多复杂。我想你必须尝试一下，看看它在实践中是否值得。

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

Answer 2

虽然这种方法从架构的角度来看是合理的，但在iOS的现实中它对性能产生了可怕的影响（之前已经尝试过并且没有很好地结束）。 iOS尽可能地缓存预先渲染的tableview单元位，因此以UIKit的设计者没有预料到的方式对不同单元的布局和外观进行运行时修改会破坏该缓存，并且性能会受到影响。

看看Matt Gallagher handles custom cell drawing是怎样的，他的方法在今年的WWDC上被Apple伪造了。此外，观看“提高响应能力的提示和技巧”和“了解UIKit渲染”sessions from WWDC，因为它们解决了改善UITableView性能的现实技术。