Java修炼终极指南:60. 处理switch中模式标签的优先级

编译器通过从上到下（或从第一到最后）的顺序，将选择器表达式与可用的模式标签进行测试，从而将选择器表达式与模式标签进行匹配。这意味着第一个匹配的标签获胜。假设我们有以下基类（Pill）和一些药片（Nurofen、Ibuprofen和Piafen）：

abstract class Pill {}
class Nurofen extends Pill {}     
class Ibuprofen extends Pill {}
class Piafen extends Pill {}   

从层次结构上讲，Nurofen、Ibuprofen和Piafen是三个位于同一层次结构级别的类，因为它们都有Pill类作为基类。在IS-A继承关系中，我们说Nurfoen是一个Pill，Ibuprogen是一个Pill，Piafen也是一个Pill。接下来，让我们使用switch为我们的客户提供适当的头痛药片：

private static String headache(Pill o) {
  return switch(o) {                      
    case Nurofen nurofen -> "Get Nurofen ...";                                   ;
    case Ibuprofen ibuprofen -> "Get Ibuprofen ...";                    
    case Piafen piafen -> "Get Piafen ...";                         
               
    default -> "Sorry, we cannot solve your headache!";
  };                      
}

调用headache(new Nurofen())将匹配第一个模式标签，Nurofen nurofen。同样，headache(new Ibuprofen())匹配第二个模式标签，headache(new Piafen())匹配第三个。不管我们如何混合这些标签案例的顺序，它们都会按预期工作，因为它们处于同一级别，没有一个支配另一个。

例如，由于人们不希望头痛，他们订购了很多Nurofen，所以我们不再有它了。我们通过移除/注释相应的案例来表示这一点：

return switch(o) {                      
  // case Nurofen nurofen -> "Get Nurofen ...";                                   ;
  case Ibuprofen ibuprofen -> "Get Ibuprofen ...";                    
  case Piafen piafen -> "Get Piafen ...";                         
               
  default -> "Sorry, we cannot solve your headache!";
};

那么，当客户想要Nurofen时会发生什么？你说得对……默认分支将采取行动，因为Ibuprofen和Piafen不匹配选择器表达式。但是，如果我们按如下方式修改switch呢？

return switch(o) {                      
  case Pill pill -> "Get a headache pill ...";            
  case Nurofen nurofen -> "Get Nurofen ...";                                               
  case Ibuprofen ibuprofen -> "Get Ibuprofen ...";                    
  case Piafen piafen -> "Get Piafen ...";                         
};

通过添加Pill基类作为模式标签案例，允许我们移除默认分支，因为我们涵盖了所有可能的值（这在问题x中有详细说明）。这次，编译器将提出错误，告知我们Pill标签案例支配了其余的标签案例。实际上，第一个标签案例Pill pill支配所有其他标签案例，因为每个匹配Nurofen nurofen、Ibuprofen ibuprofen、Piafen piafen模式的值也匹配Pill pill模式。所以，Pill pill总是赢，而其余的标签案例是无用的。通过将Pill pill与Nurofen nurofen交换，将给Nurofen nurofen一个机会，但Pill pill仍然支配其余两个。因此，我们可以通过将基类Pill的标签案例移动到最后的位置来消除Pill的支配：

return switch(o) {                                  
  case Nurofen nurofen -> "Get Nurofen ...";                                               
  case Ibuprofen ibuprofen -> "Get Ibuprofen ...";                    
  case Piafen piafen -> "Get Piafen ...";             
  case Pill pill -> "Get a headache pill ...";                        
};

现在，每个模式标签都有机会获胜。

让我们再举一个例子，从这个层次结构开始：

abstract class Drink {}
class Small extends Drink {}
class Medium extends Small {}
class Large extends Medium {}
class Extra extends Medium {}
class Huge extends Large {}
class Jumbo extends Extra {}

这次，我们有7个类，它们在基于多层层次结构中排列。如果我们排除基类Drink，我们可以将其余的类在switch中表示如下：

private static String buyDrink(Drink o) {
  return switch(o) {        
    case Jumbo j: yield "We can give a Jumbo ...";                       
    case Huge h: yield "We can give a Huge ...";                       
    case Extra e: yield "We can give a Extra ...";           
    case Large l: yield "We can give a Large ...";
    case Medium m: yield "We can give a Medium ...";                                               
    case Small s: yield "We can give a Small ...";           
    default: yield "Sorry, we don't have this drink!";
  };
}

模式标签的顺序由类层次结构强加，非常严格，但我们可以在不创建任何支配问题的情况下进行一些更改。例如，由于Extra和Large是Medium的子类，我们可以交换它们的位置。一些适用于Jumbo和Huge，因为它们都是通过Extra和Large分别通过Medium的子类。

在这种情况下，编译器通过尝试通过IS-A继承关系将选择表达式与这个层次结构匹配来评估选择表达式。例如，让我们订购一个Jumbo饮料，而没有更多的Jumbo和Extra饮料：

return switch(o) {        
  case Huge h: yield "We can give a Huge ...";                       
  case Large l: yield "We can give a Large ...";
  case Medium m: yield "We can give a Medium ...";                                               
  case Small s: yield "We can give a Small ...";           
  default: yield "Sorry, we don't have this drink!";
};

如果我们订购一个Jumbo（o是Jumbo），那么我们将得到一个Medium。为什么？编译器将Jumbo与Huge匹配不成功。将Jumbo与Large匹配也得到相同的结果。然而，当它将Jumbo与Medium匹配时，它看到Jumbo通过Extra类是Medium的子类。所以，由于Jumbo是Medium，编译器选择Medium m模式标签。在这一点上，Medium匹配Jumbo、Extra和Medium。因此，不久将也从Medium中剩下：

return switch(o) {        
  case Huge h: yield "We can give a Huge ...";                       
  case Large l: yield "We can give a Large ...";
  case Small s: yield "We can give a Small ...";           
  default: yield "Sorry, we don't have this drink!";
};

这次，任何对Jumbo、Extra、Medium或Small的请求都会给我们一个Small。我认为你已经明白了。

让我们再进一步，分析这段代码：

private static int oneHundredDividedBy(Integer value){
  return switch(value) {                             
    case Integer i -> 100/i;         
    case 0 -> 0;
  };
}

你有没有发现问题？一个模式标签案例支配了一个常量标签案例，所以编译器会抱怨第二个案例（case 0）被第一个案例支配。这是正常的，因为0也是Integer，所以它会匹配模式标签。解决方案需要交换案例：

return switch(value) {               
  case 0 -> 0;             
  case Integer i -> 100/i;             
};

这是另一个需要强化这种支配的案例：

enum Hero { CAPTAIN_AMERICA, IRON_MAN, HULK }

private static String callMyMarvelHero(Hero hero) {
  return switch(hero) {       
    case Hero h -> "Calling " + h;
    case HULK -> "Sorry, we cannot call this guy!";
  };
}

在这种情况下，常量是HULK，它被Hero h模式标签案例支配。这是正常的，因为HULK也是Marvel英雄，所以Hero h将匹配所有Marvel英雄，包括HULK。再次，修复依赖于交换案例：

return switch(hero) {       
  case HULK -> "Sorry, we cannot call this guy!";
  case Hero h -> "Calling " + h;   
};

好的，最后，让我们处理这段代码：

private static int oneHundredDividedByPositive(Integer value){
  return switch(value) {     
    case Integer i when i > 0 -> 100/i;              
    case 0 -> 0;
    case Integer i -> (-1) * 100/i;   
  };
}

你可能认为，如果我们强制Integer i模式标签与一个条件，即i严格为正，那么常量标签就不会被支配。但这不正确；一个受保护的模式标签仍然支配一个常量标签。正确的顺序首先放置常量标签，然后是受保护的模式标签，最后是非受保护的模式标签。下一个代码修复了前面的代码：

return switch(value) {     
  case 0 -> 0;
  case Integer i when i > 0 -> 100/i;  
  case Integer i -> (-1) * 100/i;

};
  

好了，我认为你已经明白了。