谈论到引用透明(Referential Transparency)，我们都会聊函数式编程(FP)，会聊Effect和Side Effect，会聊纯函数(Pure Function)等，这些概念相互关联，有时甚至彼此引用定义，能够真正理解他们的含义非常重要。
基本概念
Referential Transparency
引用Wikipedia的定义: An expression is called referentially transparent if it can be replaced with its corresponding value (and vice-versa) without changing the program's behavior. 即表达式和值可以互相替换，而对程序不产生任何影响。
Side Effect
引用Wikipedia的定义: An operation, function or expression is said to have a side effect if it modifies some state variable value(s) outside its local environment, which is to say if it has any observable effect other than its primary effect of returning a value to the invoker of the operation.
常见的Side Effect例子：
- 修改变量
- 抛出异常
- 打印日志
- 读取写入文件
Pure Function
Wikipedia的定义较长，这里总结一下，满足以下两个条件即为纯函数：
- 对所有的输入，相同的输入都有相同的输出；
- 该Function没有Side Effect；
这三个概念都是在描述不同Scope的东西，但当我们同在“函数”这一Scope内认为三个概念是等同的，即：
- 纯函数
- 没有Side Effect的函数
- 对任何入参表达式都引用透明的函数
这三个概念是等同的。由此可得，理解并能够正确判断引用透明非常重要。
用几个例子来理解引用透明
本文都以Scala进行举例。
1. 判断 method 是否引用透明
def method(): Int = 1
// One
val value = method()
someFunc(value)
// Two
someFunc(method())
是的。这是一个最基本最简单的例子，还记得上面对引用透明的定义吗，其中有三个比较重要的概念：
- expression：表达式，即这里的 method()
- value: 值，即这里的 value
- program：即这里的 someFunc(method())
表达式method()和值value可以相互替换，且对程序someFunc(method())不产生任何影响，因此这里是引用透明的。在对后续较为复杂的场景进行判断时，我们也可以用这种方式首先清晰的分辨expression，value和program，然后进一步分析。
2. 判断 method 是否引用透明
def method(): Int = {
println("evil logging >_<")
1
}
// One
val value = method()
someFunc(value) + someFunc(value)
// Two
someFunc(method()) + someFunc(method())
不透明。这里expression为method()，value为value，program为 someFunc(method())+someFunc(method())
两个program虽然返回值都是1，但program1打印了一次日志，program2打印了两次日志。即表达式和值如果相互替换，会对程序产生行为影响，故引用不透明。
3. 判断 method 是否引用透明
def method(): Int = {
println("evil logging >_<")
1
}
// One
val value = method()
someFunc(value)
// Two
someFunc(method())
引用透明吗？这里expression为method()，value为value，program为 someFunc(method())
根据定义表达式method()和值value可以互相替换，而对程序someFunc(method())不产生任何影响，那这里就是引用透明了。是吗？对吗？例子3和例子2使用了相同的表达式和值，为什么在例子2中不是引用透明的，但例子3中就是引用透明的了呢？
这是一个比较容易混淆的地方，实际上，引用透明只跟expression自己是如何实现的有关，而program只是一个抽象概念，不是某一个具体的例子。如果认为某一个表达式expression是引用透明的，那它应当在任何情况下都是透明的，如果能找到任何一个反例证明其不是引用透明的，那就是引用不透明。正如这里的例子3，我们不能只用例子中给出的program即someFunc(method())来判断，还需要思考其他program中是否也是如此，使用例子2中的program来判断就无法满足条件，因此结论是引用不透明。
用几个例子来测试是否理解引用透明
根据上面的学习结果来判断一下下面两个测试是否引用透明？答案在后面。
测试1: 判断 method 是否引用透明
def method(input: Int): Int = input
// One
val value = method(1)
someFunc(value)
// Two
someFunc(method(1))
测试2: 判断 method 是否引用透明
def method(input: Int): Int = input
// One
val value = method({ println("more evil"); 1 })
someFunc(value)
someFunc(value)
// Two
someFunc(method({ println("more evil"); 1 }))
someFunc(method({ println("more evil"); 1 }))
--------------------------------------------------答案分割线-------------------------------------------------
测试1: 引用透明。比较简单直接，不用解释。
测试2: 引用透明。但看起来可能有点奇怪，如果这里套用上面的判断方式expression是method({println(“more evil”); 1})，value是value，program是someFunc(method({println(“more evil”);1}))，那么看起来是不透明的，因为执行结果不同，program1只打印一次log，program2打印了两次log。这里要注意，Scala中代码块是可以作为参数的，这里执行结果不同，是因为另一个expression不透明，这里有一个“匿名”表达式{ println("more evil"); 1 }，任何一个expression的不透明都会导致program执行结果发生变化。
因此在函数式编程中，使expression纯很难，函数时的最终目的是compose所有的表达式，在入口处执行唯一最终组装出来的内容，要让大expression是纯的，就需要保证每一个子expression都是纯的，因此要将其有Side Effect的地方变纯，如何变纯有很多方式，是另一个话题，最简单粗暴的方式是包在一个大Monad中，让所有的Side Effect都被Monad Track住。
如何更好的设计引用透明的表达式
针对测试2的代码，method本身是引用透明的，但由于Scala代码能够将代码块作为参数，反而无意中引入了一个新的表达式，从而导致整个代码不纯，如何改进呢？
在FP的开发过程中，在做函数定义时首先要设计时使自己是引用透明的，同时注意不能相信其他部分例如入参是引用透明的，所以需要某种方式限制入参是引用透明的。
=> 改进first round：将入参变lazy，同时保证自己是引用透明的
def method(input: () => Int): () => Int = input
// One
val value = method(() => { println("more evil"); 1 })
someFunc(value)
someFunc(value)
// Two
someFunc(method(() => { println("more evil"); 1 }))
someFunc(method(() => { println("more evil"); 1 }))
这里通过限制入参必须是lazy的方式，限制method引用透明，但注意到，Lazy的入参只能保证正常流程，如果expression执行过程中发生异常呢？
=> 改进second round：引入Either类型
def method(input: () => Either[Error, Int]): () => Either[Error, Int] = input
// One
val value = method(() => {println("more evil"); Right(1)})
someFunc(value)
someFunc(value)
// Two
someFunc(() => {println("more evil"); Right(1)})
someFunc(() => {println("more evil"); Right(1)})
用Either track，保证异常流程返回Left类型，并保证每一个expression的引用透明，这也是为什么我们常见的Scala repo中会大量使用各种Monad的原因之一。
引用透明的好处
这里使用Scala来举例，因为彷佛在FP的世界会更多的提及引用透明，但实际在代码设计的过程中，不论OO还是FP，引用透明的设计都能帮助我们得到更多的好处。
Benefit 1: 更易测试
如果被测试的expression是引用透明的，那么输出只依赖于输入，编写测试case时也更加简单直接，我们只需要传入已知的入参并进行断言即可，而Mock Side Effect其实是写测试过程中很难得一个部分。比如写一段测试代码来断言在console中输出一段文字。
Benefit 2: 更易重构
如果能够判断某个expression是引用透明的，那么我们能够快速决策该表达式能够被其value替代，反之亦然。这也是很多大型遗留系统中常见的通病，系统一开始开发时，当然你好我好大家好，怎么写都无所谓，但随着时间的推移，代码量的迭代，当有相关上下文的人员逐渐离开项目，很多代码都有极大的风险变得难以维护。而如果代码库中的expression都是引用透明的，那后续开发人员也可以轻易的进行重构改动。
Benefit 3: 更易理解
如果能够判断某个函数是引用透明的，那么我们能够通过该表达式的输入输出以及少量的几行实现快速理解该expression的设计目的和想要做的事情，一共程度上与“单一设计原则”相呼应。
如果函数不是引用透明的，那么开发人员需要非常注意程序的执行顺序，同时需要复杂的各种debugger，inspection等复杂工具来检查代码，因为表达式是不透明的，所以整个代码库的任何地方任何状态都有可能发生bug。
Benefit 4: 更好设计
想象一下，如果代码中的expression都是引用透明的，那么一旦成型后续我们不需要反复多次太多的关注该expression内部的逻辑，我们可以有更多的时间来关于更重要的事情，比如系统架构、代码质量等。理论上，我们可以直接通过函数签名的命名、返回类型等快速了解其做了什么功能。因此更多的引用透明能够时开发者更加高效，并更乐于提高软件质量。**
