swift - Swift 中的特例模式是多余的吗？

Question

在 Robert Martin 的 Clean Code 一书中有一个关于何时使用 special case pattern 的 Java 示例。 .而不是这样写:

try {
  MealExpenses expenses = expenseReportDAO.getMeals(employee.getID());
  expenseTotal += expenses.getTotal();
} catch(MealExpensesNotFound e) {
  expenseTotal += getMealPerDiem();
}

我们会使用:

public class PerDiemMealExpenses implements MealExpenses {
  public int getTotal() {
  // return the per diem default
}

和

MealExpenses expenses = expenseReportDAO.getMeals(employee.getID());
expenseTotal += expenses.getTotal();

在 swift 中我们没有合并，因此我们可以跳过创建接口(interface)/协议(protocol)并立即转到:

let expenses = expenseReportCalculator.getMeals(employee.id)
expenseTotal += expenses.getTotal() ?? getMealPerDiem

这是否意味着在使用 Swift 时特例模式是多余的？也许我没有捕获要点，或者在某些特殊情况下这种模式很有值(value)。

Answer 1

我同意在 Martin 的优秀 Clean Code 的错误处理 章节的定义正常流程 部分中的这种“特殊情况”讨论。 , 有点笨拙。

正如您所指出的，Martin 的部分理由是消除重复使用 Java 的“笨拙”(他的话，不是我的话)try-catch 模式，尤其是如果你经常重复它。但是在 Swift 中，如果没有开销，你可能不会追求错误抛出模式，而只是返回一个可选的。而且，正如您所说，Swift nil-coalescing 模式与 try-catch 模式相当优雅。 (顺便说一句，Swift 可选值也与该章接下来的两节无关，不要返回 Null 和 不要传递 Null。)

Robert Martin 在这次讨论中归功于 Martin Fowler，但在 Refactoring , Fowler 在 Java 中 null 检查的挑战以及随之而来的所有问题的上下文中讨论了“特例”模式。但是 Swift 处理可选值的方式要优雅得多，这使得 Fowler 的大部分防御性-null 讨论都变得毫无意义。

所以，我同意，MealExpenses 不是 Swift 中“特例”模式的特别好的候选者。 (坦率地说，我不确定它是否是一个很好的候选者，无论如何。)Optionals 将是一个更自然的 Swift 解决方案。现在，如果我的代码到处都是相同的 nil 合并模式，我会寻找避免重复它的方法，但我不一定会跳到介绍“特殊情况” "模式仅用于此目的。

值得注意的是，在 Refactoring , Fowler 提供了一个扩展的“特例”示例，其中某个随机建筑物的房东“客户”可能是“无客户”(例如建筑物空置)、“未知客户”(您知道有租户，但您不知道它是谁)或特定客户。这种三元状态是我们必须开始思考的地方，而不是简单的 Swift 可选。但那时我们可能会使用具有关联值的 enum，或者您可以想象使用“特殊情况”模式(但现在需要引入协议(protocol))。这取决于具体情况。尽管如此，我还没有遇到过我倾向于在我的 Swift 代码中添加“特例”模式的场景。