c# - 这个开关/模式匹配的想法有什么好处吗？

Question

我最近一直在研究 F#，虽然我不太可能很快跨过这道篱笆，但它肯定突出了 C#(或库支持)可以让生活更轻松的一些领域。

特别是，我正在考虑 F# 的模式匹配功能，它允许非常丰富的语法 - 比当前的开关/条件 C# 等价物更具表现力。我不会尝试给出一个直接的例子(我的 F# 不适合它)，但简而言之，它允许:

• 按类型匹配(对可区分的联合进行全覆盖检查)[注意这也推断绑定(bind)变量的类型，提供成员访问等]
• 谓词匹配
• 上述的组合(可能还有一些我不知道的其他场景)

虽然 C# 最终借用 [咳咳] 一些这种丰富的东西会很可爱，但在此期间我一直在研究可以在运行时完成什么 - 例如，将一些对象组合在一起相当容易允许:

var getRentPrice = new Switch<Vehicle, int>()
        .Case<Motorcycle>(bike => 100 + bike.Cylinders * 10) // "bike" here is typed as Motorcycle
        .Case<Bicycle>(30) // returns a constant
        .Case<Car>(car => car.EngineType == EngineType.Diesel, car => 220 + car.Doors * 20)
        .Case<Car>(car => car.EngineType == EngineType.Gasoline, car => 200 + car.Doors * 20)
        .ElseThrow(); // or could use a Default(...) terminator

其中 getRentPrice 是一个 Func 。

[注意——也许这里的 Switch/Case 是错误的术语……但它展示了这个想法]

对我来说，这比使用重复 if/else 或复合三元条件(对于非平凡表达式变得非常困惑 - 大量括号)的等价物要清楚得多。它还避免了很多转换，并允许简单扩展(直接或通过扩展方法)到更具体的匹配，例如与 VB Select 相当的 InRange(...) 匹配。 ..案例“x 到 y”用法。

我只是想衡量人们是否认为上述结构有很多好处(在没有语言支持的情况下)？

另外请注意，我一直在玩上面的 3 个变体:

• 用于评估的 Func 版本 - 与复合三元条件语句相当
• 一个 Action 版本——相当于 if/else if/else if/else if/else
• Expression > 版本 - 作为第一个，但可由任意 LINQ 提供程序使用

此外，使用基于表达式的版本可以重写表达式树，本质上是将所有分支内联到一个复合条件表达式中，而不是使用重复调用。我最近没有检查过，但在一些早期的 Entity Framework 构建中，我似乎记得这是必要的，因为它不太喜欢 InvocationExpression。它还允许更有效地使用 LINQ-to-Objects，因为它避免了重复的委托(delegate)调用 - 测试显示与等效的 C# 相比，与上面的匹配(使用表达式形式)以相同的速度执行 [实际上稍微快一点]复合条件语句。为了完整起见，基于 Func<...> 的版本花费的时间是 C# 条件语句的 4 倍，但速度仍然非常快，在大多数用例中不太可能成为主要瓶颈。

我欢迎任何关于上述内容的想法/意见/批评/等(或关于更丰富的 C# 语言支持的可能性......希望如此 ;-p)。

Answer 1

在尝试用 C# 做这些“功能性”的事情之后(甚至尝试写一本书)，我得出的结论是，除了少数异常(exception)，这些事情并没有多大帮助。

主要原因是 F# 等语言从真正支持这些功能中获得了很大的力量。不是“你能做到”，而是“这很简单，很清楚，这是预期的”。

例如，在模式匹配中，编译器会告诉您是否存在不完全匹配，或者何时永远不会匹配到另一个匹配项。这对于开放式类型不太有用，但在匹配可区分的联合或元组时，它非常漂亮。在 F# 中，您希望人们进行模式匹配，这立即变得有意义。

“问题”在于，一旦你开始使用一些函数式概念，就很自然地想要继续下去。但是，在 C# 中利用元组、函数、部分方法应用程序和柯里化(Currying)、模式匹配、嵌套函数、泛型、monad 支持等很快就会变得非常丑陋。它很有趣，一些非常聪明的人用 C# 做了一些非常酷的事情，但实际上使用它感觉很沉重。

我最终在 C# 中经常(跨项目)使用的内容:

• 序列函数，通过 IEnumerable 的扩展方法。 ForEach 或 Process(“应用”？-- 对枚举的序列项执行操作)之类的东西很适合，因为 C# 语法支持它。
• 抽象出常见的语句模式。复杂的 try/catch/finally block 或其他涉及的(通常非常通用的)代码块。扩展 LINQ-to-SQL 也适用于此。
• 元组，在某种程度上。

** 但请注意:缺乏自动泛化和类型推断确实阻碍了这些功能的使用。 **

正如其他人所提到的，所有这一切都说明了，在一个小团队中，为了特定目的，是的，如果您坚持使用 C#，他们也许可以提供帮助。但根据我的经验，他们通常觉得麻烦多于他们的值(value) - YMMV。

其他一些链接:

• Mono.Rocks playground有许多类似的东西(以及非功能性编程但有用的补充)。
• Luca Bolognese's functional C# library
• Matthew Podwysocki's functional C# on MSDN