读函数式编程思维
读函数式编程思维
总的说下
这本书总得讲了下函数式思维，以及用各种语言来掩饰了下函数式思维。。。后面我用 swift 来演示吧
第一章 为什么要用函数式思维
函数式思维是编程范式的转换，最重要的是我们要正确的掌握语言给我们提供的特性，才能把一个语言用好
随着计算机性能提升以及编译器的不断优化，可以把一些控制权（比如内存管理，多线程等琐碎的语言细节）交给运行时来处理，用更好和更简洁的抽象来解决我们的问题
第二章 转变思维
命令式编程是按照“程序是一系列改变状态的命令”来建模的一种编程风格。
比如 for 循环处理数组，我们平时使用的时候，是通过确定初始状态，然后每次迭代都执行循环的命令，在循环的命令里面我们完成业务逻辑
函数式方法，讲程序描述为表达式和变换，以数学方程的形式建立模型，并尽可能避免可变状态
通过将数据集，进行 filter，map，reduce 等转换，得到我们想要的结果，以一种定义或是描述式的方式来处理
所有的函数式语言里面都会以不同的形式提供 filter（过滤），map（映射），reduce（折叠或者化约）
第三章 责权让渡
函数式思维的好处之一,是能够将低层次细节(如垃圾收集)的控制权移交给运行时,从 而消弭了一大批注定会发生的程序错误。开发者们可以一边熟视无睹地享受着最基本的抽 象,比如内存,一边却会对更高层次的抽象感觉突兀。然而不管层次高低,抽象的目的总 是一样的:让开发者从繁琐的运作细节里解脱出来,去解答问题中非重复性的那些方面。
- 不再使用类似
for，while之类的迭代，而是使用高阶函数，比如 map - 闭包，关注函数执行的上下文，而非通过闭包去控制状态
- 柯里化，实现函数工厂，模板方法，隐藏参数
- 递归，递归更加优雅，以及更容易让我们考虑无限的集合
- Stream 和作业顺序重排
第四章 用巧不用蛮
记忆，和缓存类似，但是不需要我们来管理，只需要在函数调用后，告诉函数需要记忆此次调用的结果，下次使用相同参数调用的时候，就不需要再次进行计算了
swift 中的参考 memoize
缓求值，不到逼不得已，不去对函数进行求值。
缓求值可以处理无限长的序列，减少存储空间占用，缓求值还有利于运行时产生高效代码
第五章 演化的语言
在面向对象的世界里，我们针对具体问题，建立专门的数据结构，以方法的形式将专门的操作关联在数据结构上。
函数式编程，只使用很少的一组关键数据结构（list，set，map）搭配专为这些数据结构深度优化过的操作。
比起在定制的类结构上做文章,把封装的单元缩小到函数级别,有利于在更基础的层面上 更细粒度地实施重用。
Clojure 很好地发挥了这方面的优势,例如在 XML 的解析问题上。 Java 语言的 XML 解析框架数量繁多,每一种都有自己的定制数据结构和方法语义(如 SAX 和 DOM 都是自成一体)。Clojure 的做法相反 ,它不鼓励使用专门的数据结构,而是 将 XML 解析成标准的 Map 结构。而 Clojure 有极为丰富的工具可以与 map 结构相配合
使用模式匹配来替代长长的 if
要想契合问题域的表达习惯,可以利用运算符重载来改变语言的外貌,不必 创造全新的语言。
函数式数据结构，使用 Either 表示两种结果的返回值，使用 Option 来表示有为空返回值的类型
第六章 模式与重用
函数式语言有函数式语言的设计模式，传统的对于函数式语言来说，因为语言的特性，让部分模式变得没有意义了，但是部分问题还是存在，他们在函数式的世界里面，通过其他的方法来解决了
传统设计模式在函数式编程的世界中大致有三种归宿。
- 模式已被吸收成为语言的一部分。
- 模式中描述的解决办法在函数式范式下依然成立,但实现细节有所变化。
- 由于在新的语言或范式下获得了原本没有的能力,产生了新的解决方案(例如很多问题都可以用元编程干净利落地解决,但 Java 没有元编程能力可用)。
函数级别的重用
因为函数式编程的特点，重用的最小单位变成了函数，并且程序由多个函数组合而成。
Template Model，通过使用函数变量，进行了化简，减少耦合
Strategy 模式，更加灵活
Flyweight 模式，使用记忆来实现
Factory 模式和柯里化，柯里化就是产出函数的工厂
以结构为载体的代码重构需要考虑整个类的关系网，可以很好的减少耦合的情况。
第七章 现实应用
Java 8 中的函数式接口，Option 类型，Stream，都是函数式语言在 Java 语言中的应用
函数试的构架，贯彻“值不可变”，学习从值不可变的角度去思考
可变的状态与测试数量有直接的关联:可变的状态越多,要求的测试也越多。
实现一个值不可变的 Java 类,我们需要做到以下事情。
-
把所有的字段都标记为final。Java 要求被标记为 final 的字段,要么在声明时初始化,要么在构造器中初始化。不要 在意 IDE 大惊小怪地提醒我们字段没有在声明位置上初始化,当我们在构造器里写好 相关的初始化代码,IDE 就会明白过来。
-
把类标记为final,防止被子类覆盖。 如果类可以被覆盖,类中的方法也就有可能被改变行为,因此以防万一,我们干脆禁止 子类化。Java 的 String 类就采取了这样的防范策略。
-
不要提供无参数的构造器。 一个值不可变的对象,它的一切状态都必须通过构造器来设定。假如我们没有需要设定 的状态,那建立这么一个对象又有何必要呢?在无状态的类里面安排几个静态方法就足 够了。所以说,值不可变的类根本不应该出现无参数的构造器。假如我们受到某些框架 的限制,不得不提供无参数的构造器,这时可以考虑能否用一个私有的无参数构造器来 满足框架的要求(私有的构造器仍然可以通过反射来访问)。 JavaBeans 的标准规定要有默认构造器,我们摒除无参数构造器违反了这条规定。不过 反正 JavaBeans 里有各种 setXXX 方法存在,本身就不可能是值不可变的。
-
提供至少一个构造器。 构造器是我们在对象里添置状态的最后机会!
-
除了构造器之外,不要提供任何制造变化的方法。我们不但要避免沿袭 JavaBeans 风格的 setXXX 方法,还必须小心防范,不能返回任何 值可变的对象引用。标记了 final 的对象引用并不等于它所指向的一切都不可改变。因 此,我们需要预防性地复制所有通过 getXXX 方法返回的对象引用。
对于 web 框架，函数式语言回很合适，因为整个 web 就是一系列从请求到响应的变换
