Java修炼终极指南:61. 处理switch中模式标签的完备性

一言以蔽之，使用null和/或模式标签的switch表达式和switch语句应该是穷尽的。换句话说，我们必须用显式的switch case标签涵盖所有可能的值。让我们考虑以下示例：

class Vehicle {}
class Car extends Vehicle {}
class Van extends Vehicle {}
   
private static String whatAmI(Vehicle vehicle) {
       
  return switch(vehicle) {
    case Car car -> "You're a car";
    case Van van -> "You're a van";       
  };
}

这段代码无法编译。错误很明显：switch表达式没有涵盖所有可能的输入值。编译器之所以抱怨，是因为我们没有Vehicle的case模式标签。这个基类可以被合法使用而不必是Car或Van，所以它是我们switch的一个有效候选项。我们可以添加一个case Vehicle或一个default标签。如果你知道Vehicle将保持一个空基类，那么你可能选择使用default标签：

return switch(vehicle) {
    case Car car -> "You're a car";
    case Van van -> "You're a van";
    default -> "I have no idea ... what are you?";       
  };

如果我们继续添加另一种车辆，例如class Truck extends Vehicle {}，那么这将由default分支处理。如果我们计划将Vehicle作为一个独立的类使用（例如，通过方法和功能来丰富它），那么我们将更倾向于添加一个case Vehicle，如下所示：

return switch(vehicle) {
    case Car car -> "You're a car";
    case Van van -> "You're a van";
    case Vehicle v -> "You're a vehicle"; // 总体模式       
};

这次，Truck类将匹配case Vehicle分支。当然，我们也可以添加一个case Truck。

Vehicle v模式被称为总体类型模式。我们可以使用两个标签来匹配所有可能的值：总体类型模式（例如，一个基类或接口）和default标签。一般来说，总体模式是一个可以代替default标签使用的模式。

在上一个示例中，我们可以通过总体模式或default标签容纳所有可能的值，但不能同时使用两者。这是有意义的，因为whatAmI(Vehicle vehicle)方法以Vehicle作为参数。因此，在这个例子中，选择器表达式只能是Vehicle或Vehicle的子类。那么，将这个方法修改为whatAmI(Object o)怎么样？

private static String whatAmI(Object o) {
       
  return switch(o) {
    case Car car -> "You're a car";
    case Van van -> "You're a van";
    case Vehicle v -> "You're a vehicle"; // 可选                
    default -> "I have no idea ... what are you?";           
  };
}

现在，选择器表达式可以是任何类型，这意味着总体模式Vehicle v不再全面。虽然Vehicle v变成了一个可选的普通模式，但新的总体模式是case Object obj。这意味着我们可以通过添加default标签或case Object obj总体模式来涵盖所有可能的值：

return switch(o) {
  case Car car -> "You're a car";
  case Van van -> "You're a van";
  case Vehicle v -> "You're a vehicle";  // 可选
  case Object obj -> "You're an object"; // 总体模式          
};

我认为你已经明白了！那么，使用接口作为基类型怎么样？例如，这里有一个基于Java内置CharSequence接口的示例：

public static String whatAmI(CharSequence cs) {
       
  return switch(cs) {           
    case String str -> "You're a string";           
    case Segment segment -> "You're a Segment";
    case CharBuffer charbuffer -> "You're a CharBuffer";
    case StringBuffer strbuffer -> "You're a StringBuffer";
    case StringBuilder strbuilder -> "You're a StringBuilder";           
  };
}   

这段代码无法编译。错误很明显：switch表达式没有涵盖所有可能的输入值。但是，如果我们查看CharSequence的文档，我们会看到它由5个类实现：CharBuffer、Segment、String、StringBuffer和StringBuilder。在我们的代码中，这些类都由模式标签覆盖，所以我们已经涵盖了所有可能的值，对吧？嗯，是也不是……“是”是因为我们目前涵盖了所有可能的值，“不是”是因为任何人都可以实现CharSequence接口，这将破坏我们switch的穷尽覆盖。我们可以这样做：

public class CoolChar implements CharSequence { … }

在这一刻，switch表达式不涵盖CoolChar类型。所以，我们仍然需要一个default标签或总体模式，case CharSequence charseq，如下所示：

return switch(cs) {           
  case String str -> "You're a string";           
  ...
  case StringBuilder strbuilder -> "You're a StringBuilder";              
  // 我们创建了这个
  case CoolChar cool -> "Welcome ... you're a CoolChar"; 
  
  // 这是一个总体模式
  case CharSequence charseq -> "You're a CharSequence";  
           
  // 可以代替总体模式使用
  // default -> "I have no idea ... what are you?";           
};

好的，让我们来处理java.lang.constant.ClassDesc内置接口的这个场景：

private static String whatAmI(ConstantDesc constantDesc) {
       
  return switch(constantDesc) {           
    case Integer i -> "You're an Integer";
    case Long l -> "You're a Long";
    case Float f -> " You're a Float";
    case Double d -> "You're a Double";
    case String s -> "You're a String";
    case ClassDesc cd -> "You're a ClassDesc";
    case DynamicConstantDesc dcd -> "You're a DCD";           
    case MethodHandleDesc mhd -> "You're a MethodHandleDesc";
    case MethodTypeDesc mtd -> "You're a MethodTypeDesc";                       
  };       
}

这段代码可以编译！没有default标签和总体模式，但switch表达式涵盖了所有可能的值。怎么会这样？！这个接口通过sealed修饰符声明为封闭的：

public sealed interface ClassDesc
extends ConstantDesc, TypeDescriptor.OfField<ClassDesc>

封闭的接口/类是在JDK 17（JEP 409）中引入的，我们将在第x章中涵盖这个话题。然而，目前，我们只需要知道封闭允许我们对继承进行细粒度控制，因此类和接口定义了它们的允许子类型。这意味着编译器可以确定switch表达式中的所有可能值。让我们考虑一个更简单的例子，如下所示：

sealed interface Player {}
final class Tennis implements Player {}
final class Football implements Player {}
final class Snooker implements Player {}  

并且，让我们有一个涵盖Player所有可能值的switch表达式：

private static String trainPlayer(Player p) {      
  return switch (p) {
    case Tennis t -> "Training the tennis player ..." + t;
    case Football f -> "Training the football player ..." + f;
    case Snooker s -> "Training the snooker player ..." + s;           
  };
}

编译器知道Player接口只有三种实现，而且它们都通过模式标签覆盖。我们可以添加一个default标签或总体模式case Player player，但大多数情况下你可能不想这样做。想象一下，我们为封闭的Player接口添加了一个名为Golf的新实现：

final class Golf implements Player {}

如果switch表达式有一个default标签，那么Golf值将由这个default分支处理。如果我们有总体模式Player player，那么这个模式将处理Golf值。另一方面，如果既不出现default标签也不出现总体模式，编译器将立即抱怨说switch表达式没有涵盖所有可能的值。所以，我们会立即得到通知，一旦我们添加了case Golf g，错误就会消失。通过这种方式，我们可以轻松维护我们的代码，并确保我们的switch表达式始终是最新的，并且涵盖所有可能的值。编译器绝不会错过通知我们Player有新实现的机会。

类似逻辑适用于Java枚举。考虑以下枚举：

private enum PlayerTypes { TENNIS, FOOTBALL, SNOOKER }

编译器知道PlayerTypes的所有可能值，所以下面的switch表达式成功编译：

private static String createPlayer(PlayerTypes p) {      
  return switch (p) {
    case TENNIS -> "Creating a tennis player ...";
    case FOOTBALL -> "Creating a football player ...";
    case SNOOKER -> "Creating a snooker player ...";              
  };
}      

再次，我们可以添加一个default标签或总体模式，case PlayerTypes pt。但是，如果我们在枚举中添加了一个新的值（例如，GOLF），编译器将把default标签或总体模式委托来处理它。另一方面，如果这些都不可用，编译器将立即抱怨说GOLF值没有被覆盖，所以我们可以添加它（case GOLF g），并在需要时创建高尔夫球手。

完成了！现在你知道如何处理switch表达式中的类型覆盖了。