内容简介:以前在iOS上,除了RAC,比较少有函数式编程方面的实践。swift对函数式做了较多的支持,随着swift的普及,在iOS社区,函数式编程被越来越多的开发者所接受。并且因为函数式编程的一些优点,也越来越多的语言开始支持函数式的开发范式。因为最近也在项目中开始实践函数式编程,也能逐渐感受到函数式强大之处。目前也有一点心得,本文就谈下自己对函数式编程的理解。
以前在iOS上,除了RAC,比较少有函数式编程方面的实践。swift对函数式做了较多的支持,随着swift的普及,在iOS社区,函数式编程被越来越多的开发者所接受。并且因为函数式编程的一些优点,也越来越多的语言开始支持函数式的开发范式。
因为最近也在项目中开始实践函数式编程,也能逐渐感受到函数式强大之处。目前也有一点心得,本文就谈下自己对函数式编程的理解。
不过在开始之前,先推荐个小段子: 好久不见
编程范式
在讲函数式编程之前,我们先来看看这两大编程范式:
- 命令式
- 声明式
来粘贴一个关于它们的定义:
命令式编程通过一系列改变程序状态的指令来完成计算。命令式编程模拟电脑运算,是行动导向的,关键在于定义解法,即“怎么做”,因而算法是显性而目标是隐性的。
声明式编程只描述程序应该完成的任务。声明式编程模拟人脑思维,是目标驱动的,关键在于描述问题,即“做什么”,因而目标是显性而算法是隐性的。
这两种范式的关键区别就在于,一个主要表达“怎么做”,一个主要表达“做什么”。通过两段代码,可以直观的感受一下它们的区别:
这两段代码都是做的同一件事,把数组里每个元素都乘2,再打印出来。
可以看出来,我们平时使用的主要都是命令式的写法,包括使用的最多的面向对象编程(OOP),其实还是属于命令式编程的范畴。而这篇文章要讲的函数式编程,则是属于声明式编程。
函数式编程的优势
- 减轻 程序员 思考的负担(防秃),降低出错的可能性
就拿上面举的例子来说,先不说一眼望去,命令式写法的复杂性就明显要高得多,即使是一个如此简单的逻辑,也容易写出错误。
当时写这个例子的时候,为了突出它们的区别,我故意没用for in range这种比较常规的写法,而使用了while,自己维护index。然鹅第一次跑起来就死循环了,再检查,发现是红框里的index加1漏了写。
函数式写法中,因为没有了状态的维护,杜绝了这种错误的发生。
- 代码可读性高
- 更简洁、更少的代码
看回定义,声明式编程描述“做什么”,目标是显性而算法是隐性的。而阅读代码时我们往往只关心代码做了什么,而不关心怎么做,这与声明式编程的思想是不谋而合的,所以函数式编程具有更高的代码可读性。
同时为了实现这种思想,算法的实现往往是内建的,或是隐藏的,这也让函数式的实现具有更少的代码,看起来更简洁。
- 适用于并发环境
- 易于优化
函数式编程中所使用的函数,大多要求为纯函数,这里可以先理解为数学意义上的函数,在相同的参数输入的情况下,一定会有同样的输出。
这一特点决定了纯函数可以并行的调用,而无需任何修改,因为无论并行与否,它都能输出正确的结果。
上图parallelMap函数的实现就是将数组分成多段,然后在多个线程中分别调用map,最后再拼回一整个。通过这一点改动,就简单的对这个程序进行了多线程的性能优化。
- 细粒度的重用(函数级别)
- 易于测试
纯函数除了之前说的,还要求“没有任何可观察的副作用,不依赖外部环境的状态”。
后半还是容易理解的,因为只要依赖了外部环境,就不能保证相同输入得到相同输出了。
前半所说的副作用,是指除了返回值外,函数还通过其他方式对调用环境产生了影响,例如修改全局变量,写文件,print到控制台等等。
纯函数很容易进行单元测试,只需关心输入输出即可。重用也是同理,不必考虑调用的顺序,不用担心影响后续逻辑,放心的复用。
- 易于重构
原因也就是前面说的那些,纯函数之间的依赖关系就是一个树,很容易理清。而对象之间的依赖就复杂得多,做过重构的同学应该都有体会,如果没有把代码看的很熟,是不敢轻易去动的。书里有一句话总结的很到位:
函数式编程指南
概念都了解了,那要怎么应用到实际的项目中呢?只要在编写代码时,往下面这几点靠,自然就能写出函数式风格的代码了:
- 只定义纯函数
- 不要用可变量
- 递归代替迭代
- 尽量少的数据结构
- 闭包、高阶函数的应用
- 尽可能使用内置的数据结构
- 尽可能使用内置的函数式工具
但是并非所有功能都适合用函数式来编写,很多情况下副作用是无法避免的:
函数式语言和逻辑式语言擅长基于数理逻辑的应用,命令式语言擅长基于业务逻辑的、尤其是交互式或事件驱动型的应用。
现阶段遇到这些情况时,还是不要强行应用函数式了,特别是苹果的系统框架还是基于面向对象的。
接下来举个:chestnut::
我们项目中有这样一个需求,在一个列表中,有多种元素(文件、文件夹、笔记等)。还有多种操作,每种操作支持的类型、数量不同。现在选中了一些元素,求能对这些元素进行哪些操作。
例如,选中一个文件、一个文件夹,这时可以进行移动操作(批量、不支持笔记),但不能进行重命名操作(只支持单个)。
这是一个很常见的需求,并且不涉及UI、交互,适合用函数式来改造一下。
最终我们需要这样一个东西,输入选择的元素列表,得到支持的操作集合。我们把它定义成Strategy类型,是一类函数,在函数式编程里,函数就是一等公民。
typealias Strategy = (_ items: [Any]) -> Set<WYOperationType>
光有Strategy还不够,我们要直接实现这样一个函数还是太过复杂,而且也不够灵活,需要把它拆解为更小的单元。
我采用的方法是,先定义一个默认的操作集合,包含了最常规的操作。然后定义一些Modifier来修改默认的操作集合。不同类型的元素支持哪些操作就定义在不同的Modifier里。
static let defaultStrategy: Strategy = { _ in [.delete, .share, .safeBoxMoveIn, .safeBoxMoveOut, .shareDirWithFriend, .rename, .download, .jumpToDir, .openIn, .favour, .move, .inbox, .unInbox, .fileInfo, .ocr, .groupMove, .noteGroup, .genPDF, .genGIF] } typealias Modifier = (_ items: [Any], _ operations: Set<WYOperationType>) -> Set<WYOperationType> class func modify(_ strategy: @escaping Strategy, _ modifier: @escaping Modifier) -> Strategy { return { items in modifier(items, strategy(items)) } }
这里的modify函数,其实就是一个带items参数的compose(组合)操作。
下面我们就来定义一个目录的modifier:
static let dirSupported: Operand = { items in let dirs = items.lazy.compactMap { $0 as? WeiyunDir } return dirs.first.map { if $0.isCollecting() { return [.share, .shareDirWithFriend, .safeBoxMoveIn, .move, .inbox, .unInbox, .delete, .rename] } else { return [.share, .shareDirWithFriend, .safeBoxMoveIn, .move, .inbox, .delete, .rename] } } } static let dirModifier: Modifier = buildModifier(dirSupported, intersection)
dirSupported判断items中是否有目录,有的话就返回目录支持的操作,通过buildModifier和intersection,构造了一个“如果含有目录,就将目前的操作集合与目录支持的操作集合取交集”的一个Modifier。
考虑到Modifier其实也就只有支持、不支持、添加三种情况,分别对应集合的交、差、并集,就通过“返回操作集合”的Operand函数,和三种SetOperation来build一个Modifier,将Modifier的逻辑也细分:
typealias SetOperation = (_ first: Set<WYOperationType>, _ second: Set<WYOperationType>) -> Set<WYOperationType> static let union: SetOperation = { $0.union($1) } static let subtracting: SetOperation = { $0.subtracting($1) } static let intersection: SetOperation = { $0.intersection($1) } typealias Operand = (_ items: [Any]) -> Set<WYOperationType>? class func buildModifier(_ operand: @escaping Operand, _ setOperation: @escaping SetOperation) -> Modifier { return { items, operations in if let ret = operand(items) { return setOperation(operations, ret) } return operations } }
下面定义了几个用于将Modifier进行组合的函数:
static let emptyModifier: Modifier = { $1 } class func concat(_ modifierLeft: @escaping Modifier, _ modifierRight: @escaping Modifier) -> Modifier { return { items, operations in return modifierRight(items, modifierLeft(items, operations)) } } class func concatModifiers(_ modifiers: [Modifier]) -> Modifier { return modifiers.reduce(emptyModifier) { concat($0, $1) } }
有了Modifier的compose函数,就可以定义更复杂的文件和笔记的Modifier了。
最后还有一个count的Modifier,是专门用来在多选的情况下,去除只支持单元素的操作。
static let fileSupported: Operand = { items in let files = items.lazy.filter { !($0 is WeiyunNote) }.compactMap { $0 as? WeiyunFile } return files.first.map { _ in [.download, .share, .shareDirWithFriend, .fileInfo, .safeBoxMoveIn, .move, .jumpToDir, .delete, .favour, .rename, .openIn, .ocr, .groupMove, .genGIF] } } static let fileUnsupported: Operand = { items in let files = items.lazy.filter { !($0 is WeiyunNote) }.compactMap { $0 as? WeiyunFile } let noOcr = files.filter { !$0.isShouldShowOCRAction() }.first let noImgVid = files.filter { !$0.isImageFile() && !$0.isVideoFile() }.first let noLivePhoto = files.filter { !$0.isLivePhoto }.first let secondFile = files.dropFirst().first let result: [WYOperationType] = (noOcr != nil ? [.ocr] : []) + (noImgVid != nil ? [.groupMove, .genGIF] : []) + (noLivePhoto != nil ? [.genGIF] : []) + (secondFile != nil ? [.genGIF] : []) return Set<WYOperationType>(result) } static let fileModifier: Modifier = concatModifiers([buildModifier(fileSupported, intersection), buildModifier(fileUnsupported, subtracting)]) static let noteSupported: Operand = { items in let notes = items.lazy.compactMap { $0 as? WeiyunNote } return notes.first.map { _ in return [.share, .delete, .noteGroup, .favour] } } static let noteUnsupported: Operand = { items in let notes = items.lazy.compactMap { $0 as? WeiyunNote } return notes.dropFirst().first.map { _ in return [.favour] } } static let noteModifier: Modifier = concatModifiers([buildModifier(noteSupported, intersection), buildModifier(noteUnsupported, subtracting)]) static let countUnsupported: Operand = { items in let wyItems = items.lazy.compactMap { $0 as? WeiyunItem } return wyItems.dropFirst().first.map { _ in return [.ocr, .fileInfo, .rename, .jumpToDir, .openIn, .inbox, .unInbox] } } static let countModifier: Modifier = buildModifier(countUnsupported, subtracting)
最后定义一个applyModifiers来应用一组Modifier:
class func applyModifiers(_ strategy: @escaping Strategy, _ modifiers: [Modifier]) -> Strategy { return modifiers.reduce(strategy) { modify($0, $1) } } static let filesTabStrategy: Strategy = applyModifiers(defaultStrategy, [dirModifier, fileModifier, noteModifier, countModifier])
filesTabStrategy就可以拿到我们APP的文件列表去用了,选中一些项目后,根据Strategy返回的操作集合来展示操作菜单。
如果其他场景有不同的需求,可以编写自己的Modifier,再与现有的一顿组合即可。
主要思想就是把函数、闭包作为数据来操作,运用于高阶函数。还要熟悉函数式编程的三板斧(map、filter、reduce)和lazy等函数式工具,遵循开头的那几个要点来编写代码,就算是入了函数式的大门了。
其他
-
纯函数的引用透明
引用透明网上有很多种解释,函数式里,是指函数运行的结果与函数本身,是可以互相替代的。显然纯函数是具有引用透明性的,所以可以延迟执行而不影响结果,这是lazy能正确执行的理论前提。
这里给出一个比较有意思的lazy filter的实现:
-
记忆
可以简单的对纯函数进行缓存,提高性能。
Swift里虽然没有内建的实现,但是自己实现一个也很简单:
生产环境使用时还要考虑内存占用、淘汰等。
-
递归代替迭代
这里实现的是“每隔1、2、3、4……个数,取一个数”。
不能使用var时,我们需要将迭代换成递归实现。好处就不再赘述了,并且符合函数式的原则。
这里需要注意的是要用上尾递归,防止爆栈。
然而我在swift上测试时,还是出现了爆栈的情况,网上查了资料说是swift不保证尾递归优化,好吧……
-
let的性能问题
纯函数式语言大概是不会出现这样的情况的,运行时的优化,数据结构的高度优化,结果应该是跟用var差不多的性能才对。至少以我的知识,都能实现一个插入时间复杂度为O(log n)的不可变字典。
swift估计是没有做这方面的优化,赋值给var时应该是发生了拷贝。并且let的dict也没有插入一个值,返回一个新let dict的方法。
-
运算符重载
-
ReactiveX
将Async、Lazy、Multi-threading版本的函数式工具,引入了面向对象编程,非常值得使用。
总结
虽然说swift引入了许多函数式编程的东西,光从“没有尾递归优化”和“不可变数据结构优化”这两点来看,实际上还是不能完全按照纯函数式语言的那一套来编码的。
函数式编程,现阶段也还不会在项目中大量运用,但是这种思维,确实可以给我们平时的编码带来不一样的启发。
以目前swift的能力来说,一些比较简单的函数式的应用还是可以胜任的。
即使在OO的编程中,这些函数式的 工具 也能够对简化代码、逻辑起到很大的作用。
参考资料
以上所述就是小编给大家介绍的《Swift函数式编程探索》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
QBasic语言程序设计教程(第2版习题解答)
刘瑞新、丁爱萍 / 电子工业出版社 / 1999-6-1 / 13.00
本书是《QBasic语言程序设计教程》(第二版)一书的配套教材、本书第一部分以概要的形式,对全书进行了总结,以便学生复习。在第二部分中,对《QBasic语言程序设计教程》(第二版)中的习题做了详尽的分析与解答。 本书也可作为QBasic语言的习题研单独使用。一起来看看 《QBasic语言程序设计教程(第2版习题解答)》 这本书的介绍吧!