特殊情况模式在Swift中是否多余？

在Robert Martin的干净代码书中，有一个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
}

及

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

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

这是否意味着在使用Swift时，特殊案例模式是冗余的？也许我没有抓住要点，或者在某些特殊情况下，这种模式是有价值的。

我同意Martin的《卓越》中错误处理一章的“定义正常流程”一节中的“特殊情况”讨论有点不严谨

正如您所指出的，Martin的部分理由是避免重复使用Java的“笨拙”（他的话，不是我的）

try

-

catch

模式，特别是如果您经常重复它的话。但在Swift中，如果没有费用，您可能不会追求错误抛出模式，而只是返回可选的。而且，正如您所说，Swift

nil

-合并模式与

try

-

catch

模式相当优雅。（顺便说一句，Swift optionals在该章的下两个部分也不相关，即不返回Null和不传递Null。）

Robert Martin在本次讨论中赞扬了Martin Fowler，但在本文中，Fowler讨论了Java中

null

检查的挑战以及由此产生的所有问题中的“特殊情况”模式。但斯威夫特处理期权的方式要优雅得多，这使得福勒的许多防守性讨论变得毫无意义

因此，我同意，

MealExpenses

不是Swift中“特殊情况”模式的特别好的候选者。（坦白地说，无论如何，我不确定它是否是一个伟大的候选人。）Optionals将是一个更自然、更迅速的解决方案。现在，如果我在代码中到处乱扔相同的

nil

合并模式，我会寻找避免重复的方法，但我不一定会为了这个目的而引入“特殊情况”模式

---

值得注意的是，在中，Fowler提供了一个扩展的“特例”示例，其中某栋随机建筑的业主“客户”可能是“无客户”（例如，该建筑是空的）、“未知客户”（您知道有租户，但您不知道是谁）或特定客户。这个三元状态是一个我们必须开始思考的超越一个简单的Swift选项的状态。但是在这一点上，我们可以使用带有关联值的

enum

，或者可以想象使用“特殊情况”模式（但现在需要引入协议）。这取决于具体情况。尽管如此，我还没有遇到过我倾向于在我的Swift代码中添加“特殊情况”模式的情况。

这是

getMealPerDiem

某个常量吗？如果是，在哪里？@JoshCaswell这是一个函数，我忘了把括号放进去。

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