首页   技术笔记   网址导航   Json在线解析   二维码   Ip地址查询   在线流程图  
新用户注册 | 会员登录
当前位置:  开发笔记 > 编程语言 > 正文

开关/模式匹配的想法

作者：手机用户2402851155 | 2023-09-04 16:34
如何解决《开关/模式匹配的想法》经验，为你挑选了7个好方法。

我最近一直在关注F#,虽然我不太可能在不久的将来跳过障碍,但它肯定会突出一些C#(或库支持)可以让生活更轻松的领域.

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

按类型匹配(对受歧视的联合进行全覆盖检查)[注意这也推断了绑定变量的类型,给成员访问等]

谓词匹配

以上的组合(以及可能我不知道的其他一些场景)

虽然C#最终可以借用[ahem]丰富的一些内容,但是在过渡时期我一直在研究可以在运行时做些什么 - 例如,将一些对象拼凑起来相当容易:

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

其中getRentPrice是Func .

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

对我来说,这比使用重复的if/else或者复合三元条件(对于非平凡的表达式变得非常混乱 - 括号丰富)的等价物要清楚得多.它还避免了大量的转换,并允许简单扩展(直接或通过扩展方法)到更具体的匹配,例如InRange(...)匹配可比VB选择...案例"x到y "用法.

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

另外请注意,我一直在玩上述3种变体:

用于评估的Func 版本 - 与复合三元条件语句相当

一个Action 版本 - 与if/else if/else if/else if/else相当

表达式>版本 - 作为第一个,但可由任意LINQ提供程序使用

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

我欢迎任何关于上述的想法/输入/批评/等(或者更富有的C#语言支持的可能性......这里希望;-p).



1> MichaelGG..：

在尝试在C#中做这样的"功能性"事情之后(甚至尝试了一本书),我得出的结论是,除了少数例外,这些事情并没有太大帮助.

主要原因是F#等语言从真正支持这些功能中获得了很大的力量.不是"你能做到",而是"它很简单,很明显,它是预期的".

例如,在模式匹配中,您可以让编译器告诉您是否存在不完整的匹配,或者是否永远不会遇到其他匹配.对于开放式类型,这不太有用,但是当匹配一个有区别的联合或元组时,它非常漂亮.在F#中,你希望人们模式匹配,它立即有意义.

"问题"是,一旦你开始使用一些功能概念,想要继续是很自然的.但是,在C#中利用元组,函数,部分方法应用程序和currying,模式匹配,嵌套函数,泛型,monad支持等变得非常难看,非常快.这很有趣,一些非常聪明的人在C#中做了一些非常酷的事情,但实际使用它感觉很重.

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

序列函数,通过IEnumerable的扩展方法.ForEach或Process("应用"？ - 对枚举的序列项执行操作)等适合,因为C#语法很好地支持它.

摘要常见的陈述模式.复杂的try/catch/finally块或其他涉及的(通常很通用的)代码块.扩展LINQ-to-SQL也适用于此处.

元组,在某种程度上.

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

所有这些都像其他人提到的那样,在一个小团队中,出于特定目的,是的,如果你坚持使用C#,也许他们可以提供帮助.但根据我的经验,他们通常觉得比他们的价值更麻烦 - YMMV.

其他一些链接:

Mono.Rocks游乐场有很多类似的东西(以及非功能性编程但有用的附加功能).

Luca Bolognese的功能性C#库

Matthew Podwysocki在MSDN上的功能性C#



2> Greg Beech..：

可以说C#不能简单地打开类型的原因是因为它主要是一种面向对象的语言,而在面向对象的术语中这样做的"正确"方法是在Vehicle上定义一个GetRentPrice方法.在派生类中覆盖它.

也就是说,我花了一些时间玩F#和Haskell这样具有这种能力的多范式和函数式语言,而且我遇到了很多以前会有用的地方(例如当你没有写出你需要打开的类型,所以你不能在它们上实现虚拟方法)这是我欢迎使用语言以及有区别的联盟.

[编辑:删除了有关性能的部分,因为Marc表示可能会被短路]

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

我倾向于使用一种解决这类问题的方法是使用一个字典字段,其中类型为键,lambda为值,使用对象初始化器语法构造非常简洁; 但是,这仅考虑具体类型,并且不允许其他谓词,因此可能不适合更复杂的情况.[旁注 - 如果你看一下C#编译器的输出,它经常将switch语句转换为基于字典的跳转表,所以似乎没有一个很好的理由它不能支持切换类型]



3> Brian..：

我不认为这些类型的库(其作用类似于语言扩展)可能会获得广泛接受,但它们很有趣,并且对于在特定领域工作的小团队非常有用.例如,如果您正在编写大量的"业务规则/逻辑",可以执行任意类型的测试,例如this和whatnot,我可以看到它将如何方便.

我不知道这是否有可能是一个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

感谢F#版本.我想我喜欢F#处理这个问题的方式,但我不确定(整体)F#目前是不是正确的选择,所以我不得不走这个中间地带......

4> 小智..：

我知道这是一个古老的话题,但在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("");
        break;
    case null:
        throw new ArgumentNullException(nameof(shape));
}



5> cdiggins..：

要回答你的问题,是的,我认为模式匹配句法结构是有用的.我想在C#中看到语法支持.

这是我的一个类的实现,它提供(几乎)与您描述的相同的语法

public class PatternMatcher
{
    List, Func>> cases = new List,Func>>();

    public PatternMatcher() { }        

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

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

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

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

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

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

    public PatternMatcher 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()
            .Case(bike => 100 + bike.Cylinders * 10) 
            .Case(30) 
            .Case(car => car.EngineType == EngineType.Diesel, car => 220 + car.Doors * 20)
            .Case(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));
        }
    }


        

6> John Leidegr..：
模式匹配(如所描述的在这里),其目的是根据其类型规范来解构值.但是,C#中类(或类型)的概念与您不一致.



多范式语言设计没有错,相反,在C#中使用lambdas非常好,而Haskell可以为IO做必要的事情.但它不是一个非常优雅的解决方案,而不是Haskell时尚.



但是,由于顺序过程编程语言可以用lambda演算来理解,而C#恰好适合顺序过程语言的参数,因此它非常适合.但是,从Haskell的纯函数上下文中获取一些东西,然后将该特性放入一种不纯粹的语言中,那就是这样做,并不能保证更好的结果.



我的观点是,使模式匹配的问题与语言设计和数据模型相关联.话虽如此,我不认为模式匹配是C#的一个有用特性,因为它不能解决典型的C#问题,也不适合命令式编程范例.

        

7> 小智..：
恕我直言,这样做的OO方式是访客模式.您的访问者成员方法只是作为案例构造,您让语言本身处理适当的调度,而不必"窥视"类型.

            

    


    


    

        
推荐阅读

        

            
        

    


    























    


    

        

            
            

                
                    devbox
                
            


            

                手机用户2402851155            


            

                这个屌丝很懒，什么也没留下！            

            
            


                                
                    
                    关注作者
                            


        

    



    

        
Tags | 热门标签

        

            
        

    



    

        
RankList | 热门文章

        

            
        

    




    








    DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6 

    Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved  devBox.cn 开发工具箱  版权所有