ios - 在委托(delegate)回调中包装手动 UItableViewCell 取消选择

Question

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

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

他还应该将其“包装”在适当的委托(delegate)回调中。原因是在这种特殊情况下(取消选择不是交互式的，而是程序性的)， TableView Controller 不会触发这些回调，因为它不知道取消选择发生时会发生。

这是 UITableView 类文档的一个片段:

Discussion

• deselectRowAtIndexPath:animated:

Calling this method does not cause the delegate to receive a tableView:willSelectRowAtIndexPath: or tableView:didSelectRowAtIndexPath: message, nor does it send UITableViewSelectionDidChangeNotification notifications to observers.

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

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

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

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

如果未触发委托(delegate)回调，则公共(public)接口(interface)中的 promise 将被破坏，并且依赖于这些回调的功能将被破坏。他说目前没有依赖于这些回调的功能，所以这是不成熟的优化。在我看来，它不是，因为目标不是违背 promise 。

我说得对吗？

Answer 1

我认为你是对的，因为一条非常明智且重要的规则:

Principle of least astonishment

The Principle of Least Astonishment states that the result of performing some operation should be obvious, consistent, and predictable, based upon the name of the operation and other clues.

如果项目中的新人将来必须实现一些新功能，当他的 UITableView 取消选择自身但不调用委托(delegate)方法时，他会惊讶 ，因为那是明显、一致且可预测的行为。这是您所说的 promise 。

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

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