条件(三元)运算符的多选等价物？

Question

我有这方面的痴迷使我的Java代码更简洁.当然有理由:我在一个屏幕上看得越多,就越容易遵循逻辑.

例如,在分配值时,可能会写:

String result;
if (arg != null) {
   result = arg.toString();
} else {
   result = "default";
}

但当然这要短得多:

String result = (arg != null) ? arg.toString() : "default";

但是,对于非布尔条件(即超过2个选项),仍然会使用该switch语句,例如:

SimpleDateFormat format;
switch (dateOrder) {
case DMY :
    format = new SimpleDateFormat("{2}" + sep + "{1}" + sep + "{0}");
    break;
case MDY :
    format = new SimpleDateFormat("{1}" + sep + "{2}" + sep + "{0}");
    break;
case YMD :
    format = new SimpleDateFormat("{0}" + sep + "{1}" + sep + "{2}");
    break;
default :
    format = null;
}

我提出了一个实用程序类,它使用泛型,lambdas和链接范例来提供如下语法:

SimpleDateFormat format = Multary.<DateOrderEnum, SimpleDateFormat>nSwitch(dateOrder)
        .nCase(DateOrderEnum.DMY, () -> new SimpleDateFormat("{2}" + sep + "{1}" + sep + "{0}"))
        .nCase(DateOrderEnum.MDY, () -> new SimpleDateFormat("{1}" + sep + "{2}" + sep + "{0}"))
        .nCase(DateOrderEnum.YMD, () -> new SimpleDateFormat("{0}" + sep + "{1}" + sep + "{2}"))
        .nDefault(() -> null)
        .result();

(该类本身很容易实现,因此我不会厌恶读者的代码.)

我的问题是:

1. 我在这里重新发明轮子吗？从搜索结果来看,我不是唯一一个有这种痒的人.以前做过类似的事吗？
2. 这有什么缺点吗？我能想到的一些包括:
   • 由于使用Map内部而不是语言构造,可能效率低下;
   • 没有编译器警告警告未使用的常数(如将在a的情况下,switch用enum) -问题(包括"没有合适的情况下,以及没有提供默认情况")可以只在运行时被检测到,以被抛出一个合适的异常;
   • 也没有编译器检查重复常量或多个默认值 - 最近的调用将是确定的.这可以再次仅在运行时检查(抛出适当的异常);
   • 放弃语句的"通过"功能case- 每个nCase()调用只使用一个常量(虽然这可以通过一些更多的代码来改善...这可能会使语法更混乱);
   • 代码自动编码可能会使链式命令混乱到不可读的混乱状态,因此需要小心地将其设置得令人满意.

Answer 1

您始终可以链接三向条件运算符:

SimpleDateFormat format = 
  dateOrder == DMY ?
    new SimpleDateFormat("{2}" + sep + "{1}" + sep + "{0}")) :
  dateOrder == MDY ?
    new SimpleDateFormat("{1}" + sep + "{2}" + sep + "{0}")) :
  dateOrder == YMD ?
    new SimpleDateFormat("{0}" + sep + "{1}" + sep + "{2}")) :
  null;