参考透明度/功能纯度是最佳实践还是取决于偏好?

时间:2012-11-26 15:36:35

标签: functional-programming referential-transparency

我想知道是否就功能纯度是否被视为最佳实践或是否取决于偏好或编程风格达成共识。换句话说,这是辩论还是有效确定?我能够找到的所有信息都表明它是一种没有缺点的美德。这是真的吗?

我想为我们当地的实践社区编制一份最佳实践清单,我想知道应该包括的程度。

2 个答案:

答案 0 :(得分:4)

最好避免突变和其他副作用,同样最好避免使用goto。也就是说,有些情况下它是有用的,但更常见的是它不能被消除并被更结构化的解决方案所取代而没有太多困难。

当然,很多都取决于您使用的语言和库。无副作用编程在非为其设计的语言中非常不方便(即几乎所有主流语言)。

独立于特定的语言约束,也可能存在可变数据结构或命令性算法的情况,在不改变大O复杂性类的情况下难以用功能性数据结构或命令性算法替代。在大多数相关案例中,目前已知好的解决方案,但有时候它们很棘手,在某些情况下还有积极的研究。

所有人都说,你可以在不失纯度的情况下产生副作用。参见例如Haskell使用monads。

答案 1 :(得分:3)

作为一般规则,您应该减少代码中的无意识复杂性。这是没有争议的。

降低复杂性的最佳方法之一是限制代码中的信息渠道 - 信息可以从一个组件“泄漏”到另一个组件的方式。这使您的代码更简单,更模块化,更易于测试,更易于使用,更易于维护。

可变变量和其他副作用是定义信息通道,与通常的函数参数和结果通道相比,它们相对“隐藏”。使用它们的代码就像一个筛子,信息通过可变变量以瞬时,时间依赖的方式泄漏进出代码。

全球可见的可变变量是最差的,因为它们(可能)泄漏整个代码库中的信息,增加了许多纠结的信息渠道来管理。局部范围的可变变量仅泄漏最多几行的时间信息。你应该避免使用前者,并且要小心后者。

因此,在最小化复杂性和增加模块性的目标中,您应该避免泄漏的副作用,因为它们会以不必要的复杂性污染您的代码。避免可变变量和其他副作用是一个很好的经验法则。