Question

我试图向我的同事解释，当他以编程方式执行此操作时：

[self.tableView deselectRowAtIndexPath:indexPath animated:NO];

他还应该在适当的委托回调中“包装”。原因是在这种特殊情况下（取消选择不是交互式，而是编程），表视图控制器不会触发这些回调，因为它不知道在发生时会发生取消选择。

以下是来自UITableView类docs的片段：

讨论


deselectRowAtIndexPath：动画：


调用此方法不会导致委托接收tableView：willSelectRowAtIndexPath：或tableView：didSelectRowAtIndexPath：message，也不会向观察者发送UITableViewSelectionDidChangeNotification通知。

所以正确的实现应该是这样的：

[self tableview:self.tableView willDeselectRowAtIndexPath:indexPath];

[self.tableView deselectRowAtIndexPath:indexPath animated:NO];

[self tableview:self.tableView didDeselectRowAtIndexPath:indexPath];

如果未触发委托回调，则公共接口中的承诺将被破坏，并且依赖于这些回调的功能将中断。他说目前没有任何功能取决于那些回调，所以它是过早的优化。在我看来，事实并非如此，因为目标并非违背承诺。

我是对的吗？

Answer 1

我认为你是对的，因为有一个非常明智和重要的规则：

<强> Principle of least astonishment

最小惊讶原则说明了结果执行某些操作应该是明显的，一致的，和可预测的，基于操作的名称和其他线索。

如果项目中的新人将来必须实施一些新功能，当他的UITableView将取消选择但不会调用委托方法时，他将惊讶，因为那＆ 明显，一致和可预测的行为。你说的是承诺。

这是打破最不惊讶规则的一个很好的例子。

现在想象一下，项目中有100个方法/对象是不可预测的。恐怖，对吧？这就是为什么这个简单的原则非常重要的原因。

Answer 2

说到“承诺”会使你的问题看起来颇具哲理性。

如果真的有必要在这种特定情况下手动执行委托调用，那么您作为开发人员必须自己或在您的团队中做出决定。

桌面视图不会自动调用其委托方法，这肯定是有原因的，因为用户实际上是否实际选择/取消选择单元格或者是否以编程方式执行此操作显然存在很大差异。有很多场景你想调用deselectRowAtIndexPath或其他匹配的方法，你可以依赖于引用对象的委托方法不会被调用的事实。

所以在我看来，在这种情况下没有 promise 这样的东西或者有义务包装你的委托调用，否则Apple可能会改变这些特定方法的行为，不会他们？

你甚至说项目中的这些调用没有功能，所以为什么要这么麻烦？：）

在委托回调中包装手动UItableViewCell取消选择

2 个答案: