引言
鹤冲天的《c#扩展方法奇思妙用》系列给了我很多启示，其中的很多用法大大提升了代码编写效率，最近小研究了一下他提供的《c#扩展方法奇思妙用变态篇三：switch/case组扩展》一文提供的扩展方法，并依照自己的习惯重新实现了一下，现分享一下我的实现。
范例
先看一下他原文中的范例：
我觉得这里唯一不爽的就是高亮的那部分，因为这里必需要显式声明类型并作后续处理，我希望直接让编译器推导出返回类型，来看看改进后的实现：
string typeName = typeId.Switch()
.CaseReturn(0, "食品")
.CaseReturn(1, "饮料")
.CaseReturn(2, "酒水")
.CaseReturn(3, "毒药")
.DefaultReturn("未知")
.ReturnValue;
在一连串的CaseReturn/DefaultReturn后通过ReturnValue属性就可以访问到最终的返回结果，这样就可以直接使用，不需再传入表达式进行后续处理了。
这样做还有一个好处，就是当代码段位于方法体中时，可以直接return结果，而如果像原文那样传入表达式来处理结果的话，是不能直接return的，在表达式里return仅会被视为表达式级别的return。
还有就是这样的代码段可以放在方法的参数中使用，这会很方便，可以将其视作三元表达式的加强版。
在原文中还有这样一种重载：
看高亮部分，这个位置的参数只是用来对判断依据进行调整，我觉得完全没有必要，写成password.Length.Switch(……)就行了呀，所以我没有依照此重载方式实现。
以我的实现方式书写的等效代码为：
private static Color GetBackColor2(string password)
{
var r = password.Length.Switch()
.CaseReturn(f => f <= 4, 255)
.CaseReturn(f => f <= 6, 192)
.CaseReturn(7, 128)
.CaseReturn(8, 64)
.DefaultReturn(0)
.ReturnValue;
return Color.FromArgb(255, 255 - r, 255 - r);
}
虽然不传入操作结果处理表达式就能安享编译器的自动推导功能，但是有时操作结果表达式还是十分有用的，比如原文中的这个范例：
这里首先让所有筛选过程都禁用了break，然后通过传入的表达式将依次返回的结果相累加。
对于这种应用来说，就必须传入自定义的表达式来对结果进行处理了，也就必须要显式声明类型了，我对此的实现也与之相仿，但是我要求传入的表达式具有两个参数，第一个参数是新获得的返回结果，第二个参数是目前的返回结果，并要求该表达式返回经过处理后的结果，以代入下一次处理或用作最终结果，等效代码为：
private static int GetReward(int count)
{
return count.Switch((int n, int o) => n + o)
.CaseReturn(f => f > 5, 1, false)
.CaseReturn(f => f > 10, 10, false)
.CaseReturn(f => f > 20, 100, false)
.CaseReturn(f => f > 50, 1000, false)
.CaseReturn(f => f > 100, 1000)
.ReturnValue;
}
有人可能奇怪，为什么方法名都是CaseReturn、DefaultReturn这样的带个Return呢？这不是很啰嗦嘛？直接以Case命名不好吗？
这是因为我还实现了另一种形式：无返回值形式
参看下面的代码：
private void Form1_FormClosing(object sender, FormClosingEventArgs e)
{
if (IsBusy)
MessageBox.Show(@"下载正在进行中，是否要关闭此窗口并中止下载？
是 - 关闭窗口并中止下载
否 - 仅关闭窗口，不中止下载
取消 - 不进行任何操作", "提示"
, MessageBoxButtons.YesNoCancel, MessageBoxIcon.Question).Switch()
.CaseRun(DialogResult.Yes, f => this.Stop())
.CaseRun(DialogResult.No, f => { })
.DefaultRun(f => e.Cancel = true);
}
这段代码通过CaseRun、DefaultRun方法执行传入的表达式，其功能就是根据不同对话框选项进行不同的处理，很容易理解。
之所以将CaseRun与CaseReturn区别命名，而不是重载，是因为CaseReturn也有类似于CaseRun的重载，即第二个参数也是表达式的重载。
虽然CaseReturn的重载中要求传入的表达式要有返回值（Func<T,T>），而CaseRun的第二个参数不要求返回值（Action<T>），但是在传入单句的Lambda表达式的时候容易产生歧义。
比如表达式中执行了一个带有返回值的方法，由于单句Lambda表达式不需显式使用return关键字，所以编译器就不能确切推导出要执行的是哪一个重载，这样编译器就可能会抓狂，然后其视为最吻合的Func<T,T>形式重载，而编写者可能仅仅是想执行一下该方法，并不希望获取返回值并反映到结果中去。
（情景范例：在单句Lambda表达式中调用了对数据库执行SQL语句的方法，该方法会返回受影响的记录总数，而程序员可能是希望仅仅执行一下SQL语句就好了，但恰巧此Switch()方法链的返回结果被推导为int类型，程序就将此表达式匹配到Func<T,T>形式重载，就这样糊里糊涂地让这个返回值影响到了最终的返回结果）
所以如果不区别命名的话，在第二个参数中通过单句Lambda表达式执行带有返回值的方法时，程序就会倾向按照Func<T,T>的形式来执行，如是这样的话，出现问题的可能性不大，但一旦赶巧出现歧义判定问题，就很烦人，而且很难查出来，故此我要保留这种区别命名的形式。
要点提示
在使用中，以上展示的各种方法及其重载都可以混搭使用，但需注意以下几点：
- Default类方法仅允许在语句链的末端使用，但其后可以追加同类的多个方法。
确切的说应该是：Default类方法的后面不允许再使用Case类方法。 - 在Switch()之后，只有当首次书写CaseReturn方法时，返回结果的类型才被定性，此后的所有CaseReturn方法都将要遵从此类型。
因为在Switch()方法里没有显式声明任何类型，所以这个返回类型推导工作被延后到首次书写CaseReturn方法时完成。
Switch的有参数重载形式不具备此延迟推导特性。 - 如果一直没有书写CaseReturn方法，那么在书写DefaultRun方法后，方法链将结束，无法书写后续的方法链，也无法获取返回结果。
这个设计是很自然的，因为其后书写什么都没有什么实际意义了，这里提示出来就是怕不知道的人误以为是BUG。
不只是替代switch
由于这个Switch扩展方案支持传入表达式做判定和执行，所以它还完全可以用于替代if……else if……else语句，比如下面代码中，底部的那段代码与注释掉的那段代码就是等价的：
var str = "test";
var on=true;
var day = DateTime.Today;
//if (str.StartsWith("t") && on) str = "1";
//else if (str.Length > 9) str = "2";
//else if (str == "none") { str = "3"; on = false; }
//else if (day < DateTime.Now) str = "4";
//else on = false;
str.Switch()
.CaseRun(f => f.StartsWith("t") && on, f => str = "1")
.CaseRun(f => f.Length > 9, f => str = "2")
.CaseRun("none", f => { str = "3"; on = false; })
.CaseRun(f => day < DateTime.Now, f => str = "4")
.DefaultRun(f => on = false);
扩展的意义
这样的扩展除了让代码显得更复杂以衬托出作者之牛B深奥之外，还有什么优点？
优点就是能在单句Lambda表达式中使用，这样就能让你更深奥一层……
哈哈，玩笑，不只是单句Lambda表达式，在充当方法的参数时，三元表达式又不够用的情况下，这样的扩展就大有用武之地了，你可以不必大费周章地再去定义临时的变量并给它赋值，或者专门建立一个方法来解决这类简单的判别问题。
它的形式可能不算优雅，但它能够让你的代码结构变得优雅一些，并让你专注于解决手头的问题，而不是在代码页中上翻下抄瞎忙活。
总结
再次感谢鹤冲天给我们带来了那么多的启示，让我们一同将扩展方法发挥到淋漓尽致吧，这是我们自制的语法糖啊：）
下载
扩展方法源代码：http://www.uushare.com/user/icesee/file/2155948
本文的XPS版本：http://www.uushare.com/user/icesee/file/2155951