当谈论引用透明时，我们在说什么

谈论到引用透明(Referential Transparency)，我们都会聊函数式编程(FP)，会聊Effect和Side Effect，会聊纯函数(Pure Function)等，这些概念相互关联，有时甚至彼此引用定义，能够真正理解它们的含义非常重要。

使用了引用透明，可以为我们带来诸多好处，让我们的代码更易于设计，方便测试和重构，读起来也更容易理解。

用几个例子来测试是否理解引用透明

判断一下下面两个测试是否引用透明？答案在后面。(本文都以Scala进行举例)

测试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: 引用透明。

测试1是比较简单常见的例子，也比较容易理解，但是测试2可能就没那么容易明白了，如果还没彻底想清楚，那么继续往下看吧！

基本概念

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的定义较长，这里总结一下，满足以下两个条件即为纯函数：

1. 对所有的输入，相同的输入都有相同的输出；
2. 该Function没有Side Effect；

而事实上，这三个概念都是在描述不同Scope的东西，我们同在“函数”这一Scope内认为三个概念是等同的，即：

• 纯函数
• 没有Side Effect的函数
• 对任何入参表达式都引用透明的函数

这三个概念是等同的。由此可得，理解并能够正确判断引用透明非常重要。

用几个例子来理解引用透明

1. 判断 method 是否引用透明

def method(): Int = 1

// One
val value = method()
someFunc(value)

// Two
someFunc(method())

透明。这是一个最基本最简单的例子，还记得上面对引用透明的定义吗，其中有三个比较重要的概念：

1. expression：表达式，即这里的 method()
2. value: 值，即这里的 value
3. 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来判断就无法满足条件，因此结论是引用不透明。

回到开头的例子

根据上面的学习结果来再次分析一下开头的测试2为什么是引用透明的：

测试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 }))

测试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 pure很难，函数时的最终目的是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的原因之一。

以上就是关于引用透明的一些例子和分享，在实际的日常FP开发中，我们经常会面临类似的问题，这就需要我们除了能够正确引用第三方的FP库之外，还能够写出更加FP的代码，因此正确理解和使用透明这一概念非常重要。

文/Thoughtworks 王亚鑫 袁迪
原文链接：https://insights.thoughtworks.cn/how-to-referential-transparency/