常用编程范式
大概有四种，如果按照类似继承图谱来看的话，应该如下图：
函数式编程（Functional Program,FP）
函数式编程是使用函数来编程的一种编程范式
无副作用
实际上函数编程需要可观测的作用，例如把结果显示在屏幕上。换句话说与外界的交互不会发生在计算过程中，而是发生在计算完成后——将会推迟副作用并单独应用
函数式编程就是编写非有意副作用的程序，如果需要副作用尽可能的延迟副作用发生的时机。如果既有返回值又有副作用，这种程序就不是函数式。
引用透明
函数式程序的输出只能取决于自己的参数，这就意味着函数式代码不能从控制台、文件等读取数据，既函数式代码是引用透明的（不被外界影响到的代码是引用透明的）。
引用透明代码的特点：
- 它是独立的。不依赖与任何外部设备，可以在任何上下文中使用它——只需要提供一个有效的参数。
- 它是确定的。在引用透明的代码中，不会有意外发生，结果可能是错误的，但是一个参数对应的结果肯定是相同的。
- 它绝对不会抛出任何的Exception。但是它可能会抛出错误（不是异常）——抛出error。例如OOME或者SOE，这些表示代码有bug，并不是作为程序员的你或是你api的用户应该处理的——当然修复这个bug肯定是你要做的。
- 任何时候它都不会导致其他代码意外失败。例如他不会改变参数或者外界数据，从而导致调用者发现自己的数据过期或者并发访问异常。
- 它不会由于外部设备（数据库、文件系统）不可用、太慢或坏掉而崩溃——但是你的程序会。
优势
- 函数式程序更加易于推断，因为他们有确定性。确定的输入会有确定的输出，在许多情况下可以证明程序是正确的，而不是在大量测试后仍然无法确定程序是否会在意外情况下出错。
- 函数式程序更加易于测试。没有副作用，所以不需要那些经常用于在测试里隔离程序及外界的mock。
- 函数式程序更加模块化，只关心输入和输出，不用去处理异常，处理副作用，不用关心上下文变化，并发等。
- 函数式编程让符合和重新符合更加简单。基础函数组成高级别函数，因为要用骨头吗，所以无须修改就可以为其他程序所重用——例如编写了一个求和函数，A程序可以用，B程序也可以用。
- 函数式程序总是线程安全的，因为防止了共享状态的变化。并不意外这所有数据都不需要改变，只有共享数据才需要。
响应式编程(Reactive Programming:RP)
响应式编程是一种面向数据流和变化传播的编程范式
这意味着可以在编程语言中很方便地表达静态或动态的数据流，而相关的计算模型会自动将变化的值通过数据流进行传播。
响应式编程最初是为了简化交互式用户界面的创建和实时系统动画的绘制而提出来的一种方法，但它本质上是一种通用的编程范式。
以程序开发过程为例，
程序接收输入产生输出。输出就是对输入做了一些事的结果。输入，转换，输出，完成。
输入是应用动作的全部来源。点击、键盘事件、定时器事件、GPS时间、网络请求响应都算是输入。这些事件被传递到应用中，应用将他们以某种方式混合，产生了结果：就是输出。
输出通常会改变应用的UI。开关状态变化、列表有了新的元素都是UI变化。也有可能让磁盘上某个文件产生变化，或者产生一个API请求，这都是应用的输出。
应用的输入输出可以产生很多次。
应用打开后，不只是一个简单的 输入→工作→输出 就构成了一个生命周期。应用经常有大量的输入并基于这些输入产生输出。
- 响应式编程是一种和
事件流有关的编程模式，关注导致状态值改变的行为事件，一系列事件组成了事件流。- 一系列事件是导致属性值发生变化的原因。FRP非常
类似于设计模式里的观察者模式。- RP与普通的函数式编程相似，但是每个函数可以接收一个输入值的流，如果其中，一个新的输入值到达的话，这个函数将根据最新的输入值重新计算，并且产生一个新的输出。这是一种”数据流”编程模式。
为什么用响应式?
- 开发过程中，状态以及状态之间依赖过多，RAC更加有效率地处理事件流，而无需显式去管理状态。在OO或者过程式编程中，状态变化是最难跟踪，最头痛的事。这个也是最重要的一点。
- 减少变量的使用，由于它跟踪状态和值的变化，因此不需要再申明变量不断地观察状态和更新值。
- 提供统一的消息传递机制，将oc中的通知，action，KVO以及其它所有UIControl事件的变化都进行监控，当变化发生时，就会传递事件和值。
- 当值随着事件变换时，可以使用map，filter，reduce等函数便利地对值进行变换操作。
函数响应式编程(Functional Reactive Programming:FRP)
响应式编程思想为体, 函数式编程思想为用
可以结合ReactiveCocoa（简称RAC）来理解，
RAC结合了几种编程风格：
函数式编程（Functional Programming）：使用高阶函数。比如函数用其它函数作为參数。
响应式编程（Reactive Programming）：关注于数据流和变化传播。
所以，你可能听说过ReactiveCocoa被描写叙述为函数响应式编程（FRP）框架。
有句比喻非常好非常形象的对RAC做了总结：
“能够把信号想象成水龙头，仅仅只是里面不是水，而是玻璃球(value)，直径跟水管的内径一样，这样就能保证玻璃球是依次排列。不会出现并排的情况(数据都是线性处理的，不会出现并发情况)。水龙头的开关默认是关的。除非有了接收方(subscriber)，才会打开。
这样仅仅要有新的玻璃球进来，就会自己主动传送给接收方。
能够在水龙头上加一个过滤嘴(filter)。不符合的不让通过，也能够加一个修改装置，把球改变成符合自己的需求(map)。
也能够把多个水龙头合并成一个新的水龙头(combineLatest:reduce:)，这样仅仅要当中的一个水龙头有玻璃球出来，这个新合并的水龙头就会得到这个球。”
RXSwift
RxSwift 是 ReactiveX 针对Swift 的实现。
RxSwift是一个针对于Swift语言的响应式编程框架，旨在使异步操作和事件/数据流的实现变的简单。
Observables 和 Observers
两个基本概念：Observable和Observer。
- Observable是发出变化通知的对象。
- Observer是监听Observable的对象。当Observable变化时，Observer会收到通知。
可以有多个Observer监听同一个Observable。当Observable发生变化时，会通知它所有的Observer。
DisposeBag
DisposeBag是用来处理 ARC 和内存管理的。 DisposeBag是Observer 对象的一个虚拟包，当Observer的父对象被释放时，这个虚拟包会被丢弃。
当带有DisposeBag属性的对象的 deinit()方法被调用时，DisposeBag会清空，并且每一个用完即丢弃(disposable)的Observer 会自动取消对观察内容的监听。这可以让 ARC 正常的回收内存。
如果没有DisposeBag，会有两种后果：要么Observer会产生一个 retain cycle，将无限期的进行监听；要么Observer被意外释放，导致程序崩溃。
所以在设置Observable对象时，将其添加到DisposeBag中。
核心逻辑
可以参考我的博客RXSwift-核心逻辑，RXSwift正式基于这样的核心逻辑才实现函数响应式编程。
