面向过程,面向对象,函数式对同一个问题的思考方式

我之所以对函数式代码感兴趣是因为函数式代码富有表现力,可以使用简短、紧凑的代码完成工作,同时能对特定的问题给出优雅的解决方案。现代的编程语言不约而同的朝着面向对象、函数式、动态、解释执行的方向发展,例如Ruby,Swift。而另一些语言则更加强调函数式编程,如F#,Scala,这种语言有着强大的类型推断系统,编写的代码洁程度则令人叹为观止。

在F#编写一个两个数相加的函数,在F# Interactive中输入:

F# Interactive为我们推断了这个函数类型:val add : num1:int -> num2:int -> int,表示add有两个int类型的参数得到了1个int类型。

函数当作参数:

使用F#则只需要非常简洁的一个函数声明:

val twice : input:int -> f:(int -> int) –> int 这句话则是F# Interactive给出的推断:twice函数需要一个int参数和一个(int->int)的函数作为参数,返回一个int.

这两个例子仅仅是热身,并不是本篇博客的重点,所以你觉得前两个例子很无聊或者没太看明白请继续看下面的总结。

场景:某种活动会有一个日程安排(Schedule),日程安排有3中类型,只举办一次(Once),每天一次(Daily),每周一次(Weekly)。活动会根据日程安排(Schedule)的类型不同具有不同的宣传内容,不同的延期举行策略。

你对于这样的场景会有怎么样的思考呢?

一、面向过程类型的编码方式

面向过程类型的编码是需求的直译过程,代码会写成这样:

1.显示活动的宣传内容:

这样的代码初次看起来没什么问题,实际存在两个危险信号:

  • 违反开放封闭(OCP)原则,如果有一天需要加入一种Monthly类型,无疑需要修改这个方法;
  • 这样的代码风格会让接下来的开发者不假思索的进行延续,比方说需要根据不同的活动类型延期活动;

2. 延期活动:

这样的代格违反了DRY原则,相同的代码框架却无法重用。

二、面向对象的编码方式

对于一个有经验的OO开发者,一旦看到switch,if(type=typeof(…))之类的代码马上会提高警惕,是不是有一些抽象类型没有被找出来?在这个例子中则会找出下面的抽象:

这样的代码很好的解决了面向过程代码的两个问题,看起来更加具有扩展性,随着新类型的Schedule引入,旧的代码完全不用改动。

当然事情也不是绝对的,什么情况下需要改动旧代码呢?当需要扩展Schedule的行为的时候,例如需求升级,不同的Schedule具有不同的举办方式,我们不得不在每种Schedule中加入一个 void Hold()方法。

三、函数式解决方案

函数式语言则使用可区分联合和模式匹配来处理此类问题。

定义一个Schedule可区分联合:

这个类型既说明了Schedule有三个不同的类型,同时定义了三种类型分别具有的数据结构。像是Enum和类的综合体,但是又显得特别精致。

1.显示活动的宣传内容,使用了模式匹配:

这个方法类似于switch…case,但是通过匹配可区分联合来实现,而不是通过一个显示的Enum来实现。

2. 延期活动:

函数式编程的解决方案认为可以很方便的添加新的行为,例如增加新的行为:Hold()。通过定义可区分联合和模式匹配来完成编码,整个解决方案像是面向过程和面向对象的一种结合体,但是侧重点不同,实现的代码也更加精致。

1 3 收藏 2 评论

相关文章

可能感兴趣的话题



直接登录
最新评论
跳到底部
返回顶部