这种转换/模式匹配的想法有什么好处吗？

我最近一直在关注 F # ，虽然我不太可能在短期内越过栅栏，但它确实突出了 C # (或库支持)可以让生活变得更轻松的一些领域。

我特别想到的是 F # 的模式匹配功能，它允许非常丰富的语法——比当前的 switch/条件 C # 等价物更具表现力。我不会试图给出一个直接的例子(我的 F # 不能胜任) ，但简而言之，它允许:

  • 通过类型匹配(对有区别的联合进行全覆盖检查)[注意，这也推断出绑定变量的类型，允许成员访问等]
  • 一个谓词一个谓词地匹配
  • 上述情况的组合(可能还有其他一些我不知道的情况)

虽然 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 < Vehicle，int > 。

[注意-也许 Switch/Case 这里的术语是错误的... ... 但它显示了想法]

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

我只是试图估计人们是否认为像上面这样的结构(在缺乏语言支持的情况下)有很多好处？

另外请注意，我一直在使用以上三种变体:

  • 用于计算的 Func < TSource，TValue > 版本-与复合三元条件语句相当
  • Action < TSource > 版本-类似于 if/else if/else if/else
  • 表达式 < Func < TSource，TValue > version-作为第一个表达式，但可供任意 LINQ 提供程序使用

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

我欢迎任何关于上述(或者更丰富的 C # 语言支持的可能性)的想法/输入/评论/等等。

25428 次浏览
小开

虽然它不是非常’C-sharpey’开关类型，我知道构造将是非常有帮助的一般使用-我至少有一个个人项目，可以使用它(虽然它的可管理 ATM)。在重写表达式树时，是否存在编译性能问题？

小开

我不认为这些类型的库(其作用类似于语言扩展)可能会得到广泛的认可，但是它们很好玩，并且对于在特定领域工作的小团队非常有用。例如，如果您正在编写大量的“业务规则/逻辑”，这些规则/逻辑执行诸如此类的任意类型测试，那么我可以看到它是多么方便。

我不知道这是否有可能成为 C # 语言的一个特性(似乎令人怀疑，但谁能预见未来呢?).

作为参考，相应的 F # 大约是:

let getRentPrice (v : Vehicle) =
match v with
| :? Motorcycle as bike -> 100 + bike.Cylinders * 10
| :? Bicycle -> 30
| :? Car as car when car.EngineType = Diesel -> 220 + car.Doors * 20
| :? Car as car when car.EngineType = Gasoline -> 200 + car.Doors * 20
| _ -> failwith "blah"

假设您已经按照

type Vehicle() = class end


type Motorcycle(cyl : int) =
inherit Vehicle()
member this.Cylinders = cyl


type Bicycle() = inherit Vehicle()


type EngineType = Diesel | Gasoline


type Car(engType : EngineType, doors : int) =
inherit Vehicle()
member this.EngineType = engType
member this.Doors = doors
小开

可以说，C # 之所以不能简单地打开类型，是因为它基本上是一种面向对象的语言，用面向对象的术语来说，“正确”的方法是在汽车上定义一个 GetRentPrice 方法，并在派生类中覆盖它。

也就是说，我已经花了一些时间来玩多范式和函数式语言，比如 F # 和 Haskell，它们都有这样的功能，而且我以前也遇到过很多有用的地方(例如，当你没有编写你需要打开的类型，所以你不能在它们上面实现虚方法) ，这是我欢迎进入这门语言的一些东西，以及有区别的联合。

[编辑: 删除部分性能，因为马克表示它可能会短路]

另一个潜在的问题是可用性问题——从最终调用可以清楚地看到，如果匹配不符合任何条件，会发生什么情况，但是如果匹配了两个或更多条件，会发生什么行为？它应该抛出一个异常吗？它应该返回第一个匹配项还是最后一个匹配项？

我解决这类问题的一个方法是使用一个 dictionary 字段，类型作为键，lambda 作为值，使用对象初始化器语法构造这个字段非常简洁; 然而，这只考虑了具体的类型，并且不允许额外的谓词，所以可能不适合更复杂的情况。[附注-如果你看 C # 编译器的输出，它经常将 switch 语句转换为基于字典的跳转表，所以它似乎没有理由不支持类型切换]

小开

需要注意的一点是: C # 编译器非常擅长优化 switch 语句。不只是短路-你得到完全不同的 IL 取决于多少情况下，你有等。

您的特定示例确实做了一些我认为非常有用的事情——没有语法等效于逐个类型的大小写，因为(例如) typeof(Motorcycle)不是一个常量。

这在动态应用程序中变得更加有趣——这里的逻辑可以很容易地由数据驱动，提供“规则引擎”样式的执行。

小开

在尝试用 C # 做这些“函数式”的事情(甚至尝试写一本关于它的书)之后，我得出的结论是，不，除了少数例外，这些事情没有太大帮助。

主要原因是像 F # 这样的语言从真正支持这些特性中获得了很大的力量。不是“你能做到”，而是“这很简单，很明显，这是预料之中的”。

例如，在模式匹配中，编译器会告诉你是否存在不完全匹配，或者什么时候永远不会碰到另一个匹配。这对于开放式类型没有多大用处，但是当匹配有区别的联合或元组时，它非常有用。在 F # 中，您希望人们进行模式匹配，这样做立即就有意义了。

问题在于，一旦您开始使用某些函数概念，就很自然地希望继续使用。然而，在 C # 中利用元组、函数、部分方法应用程序和局部套用、模式匹配、嵌套函数、泛型、单子支持等，很快就会使 非常变得很丑陋。它很有趣，一些非常聪明的人已经在 C # 中做了一些非常酷的事情，但实际上 使用感觉很沉重。

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

  • 序列函数，通过 IEnumable 的扩展方法。比如 ForEach 或者 Process (“ Apply”？--对枚举的序列项执行操作) ，因为 C # 语法很好地支持它。
  • 抽象常见语句模式。复杂的 try/catch/finally 块或其他相关(通常是非常泛型的)代码块。扩展 LINQ-to-SQL 也适合这里。
  • 在某种程度上，是元组。

但是请注意: 缺乏自动泛化和类型推断实际上阻碍了这些特性的使用。**

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

其他连结:

小开

在我看来，做这些事情的面向对象的方法是访问者模式。您的访问者成员方法只是充当 case 构造，您让语言本身处理适当的分派，而不必“窥视”类型。

小开

模式匹配的目的(如 给你所述)是根据其类型规格解构数值。然而，C # 中类(或类型)的概念并不适合您。

多模式语言设计并没有什么错，相反，在 c # 中使用 lambdas 非常好，哈斯克尔可以对 IO 做命令式的东西。但这不是一个非常优雅的解决方案，不符合哈斯克尔的时尚。

但是由于序列程序编程语言可以用 lambda 演算来理解，而且 C # 恰好符合序列工作语言的参数，所以它是一个很好的选择。但是，从 Haskell 的纯函数上下文中获取一些内容，然后将该特性放入一种非纯函数的语言中，这样做并不能保证得到更好的结果。

我的观点是，模式匹配的成功与语言设计和数据模型有关。尽管如此，我不认为模式匹配是 C # 的一个有用的特性，因为它不能解决典型的 C # 问题，也不能很好地适应命令式编程范式。

小开

是的，我认为模式匹配句法结构是有用的。就我个人而言，我希望看到 C # 对它的语法支持。

下面是我实现的一个类，它提供了(几乎)与您描述的相同的语法

public class PatternMatcher<Output>
{
List<Tuple<Predicate<Object>, Func<Object, Output>>> cases = new List<Tuple<Predicate<object>,Func<object,Output>>>();


public PatternMatcher() { }


public PatternMatcher<Output> Case(Predicate<Object> condition, Func<Object, Output> function)
{
cases.Add(new Tuple<Predicate<Object>, Func<Object, Output>>(condition, function));
return this;
}


public PatternMatcher<Output> Case<T>(Predicate<T> condition, Func<T, Output> function)
{
return Case(
o => o is T && condition((T)o),
o => function((T)o));
}


public PatternMatcher<Output> Case<T>(Func<T, Output> function)
{
return Case(
o => o is T,
o => function((T)o));
}


public PatternMatcher<Output> Case<T>(Predicate<T> condition, Output o)
{
return Case(condition, x => o);
}


public PatternMatcher<Output> Case<T>(Output o)
{
return Case<T>(x => o);
}


public PatternMatcher<Output> Default(Func<Object, Output> function)
{
return Case(o => true, function);
}


public PatternMatcher<Output> Default(Output o)
{
return Default(x => o);
}


public Output Match(Object o)
{
foreach (var tuple in cases)
if (tuple.Item1(o))
return tuple.Item2(o);
throw new Exception("Failed to match");
}
}

下面是一些测试代码:

    public enum EngineType
{
Diesel,
Gasoline
}


public class Bicycle
{
public int Cylinders;
}


public class Car
{
public EngineType EngineType;
public int Doors;
}


public class MotorCycle
{
public int Cylinders;
}


public void Run()
{
var getRentPrice = new PatternMatcher<int>()
.Case<MotorCycle>(bike => 100 + bike.Cylinders * 10)
.Case<Bicycle>(30)
.Case<Car>(car => car.EngineType == EngineType.Diesel, car => 220 + car.Doors * 20)
.Case<Car>(car => car.EngineType == EngineType.Gasoline, car => 200 + car.Doors * 20)
.Default(0);


var vehicles = new object[] {
new Car { EngineType = EngineType.Diesel, Doors = 2 },
new Car { EngineType = EngineType.Diesel, Doors = 4 },
new Car { EngineType = EngineType.Gasoline, Doors = 3 },
new Car { EngineType = EngineType.Gasoline, Doors = 5 },
new Bicycle(),
new MotorCycle { Cylinders = 2 },
new MotorCycle { Cylinders = 3 },
};


foreach (var v in vehicles)
{
Console.WriteLine("Vehicle of type {0} costs {1} to rent", v.GetType(), getRentPrice.Match(v));
}
}
小开

您可以通过使用我编写的一个名为 其中之一的库来实现您所追求的目标

与 switch(以及 if和 exceptions as control flow)相比，主要的优势在于它是编译时安全的——没有默认处理程序或失败

   OneOf<Motorcycle, Bicycle, Car> vehicle = ... //assign from one of those types
var getRentPrice = vehicle
.Match(
bike => 100 + bike.Cylinders * 10, // "bike" here is typed as Motorcycle
bike => 30, // returns a constant
car => car.EngineType.Match(
diesel => 220 + car.Doors * 20
petrol => 200 + car.Doors * 20
)
);

在 Nuget 上，目标是 net451和 netstandard 1.6

小开
最佳答案

在 C # 7中，你可以这样做:

switch(shape)
{
case Circle c:
WriteLine($"circle with radius {c.Radius}");
break;
case Rectangle s when (s.Length == s.Height):
WriteLine($"{s.Length} x {s.Height} square");
break;
case Rectangle r:
WriteLine($"{r.Length} x {r.Height} rectangle");
break;
default:
WriteLine("<unknown shape>");
break;
case null:
throw new ArgumentNullException(nameof(shape));
}

提交答案