在Python中使用函数式编程的最佳实践！(3)

第一次运行 test_pluraize 时该测试能够通过，但以后每次运行都会失败，因为它会反复添加“s”和“es”。为了让它变成纯函数， 可以这样写：

dictionary = ['fox', 'boss', 'orange', 'toes', 'fairy', 'cup']  
def puralize(words):  
 result = []  
 for word in words:  
 word = words[i]  
 if word.endswith('s') or word.endswith('x'):  
 plural = word + 'es')  
 if word.endswith('y'):  
 plural = word[:-1] + 'ies'  
 else:  
 plural = + 's'  
 result.append(plural)  
 return result  
def test_pluralize():  
 result = pluralize(dictionary)  
 assert result == ['foxes', 'bosses', 'oranges', 'toeses', 'fairies', 'cups'] 

注意这里并没有使用任何 FP 特有的概念，只是创建并返回了一个新的对象，而不是重用并修改已有的旧对象。这样输入的内容也会保持不变。

虽然这个例子像个玩具，但想象一下，如果你传递并改变了某个复杂的对象，或者通过数据库连接进行了某些操作。当编写很多很多测试用例时就会发现，你必须非常小心地处理测试用例的顺序，或者花大量代价在每个测试用例之后清除并重新创建状态。这些工作应该是在 e2e 集成测试阶段的活儿，不应该在比较小的单元测试阶段进行。

理解（并避免）可修改性

先来个调查，你认为哪些数据结构是可修改的？

为什么这一点很重要？有些时候列表和元组可以互换使用，因此人们经常会在代码中随机使用两者之一。于是当你试图修改一个元组（比如给其中一个元素赋值）时就会出错。或者试图用列表作为字典的键，也会导致 TypeError，因为列表是可修改的。元组和字符串可以作为字典的键使用，因为它们不可修改，可以得到确定的哈希值，而其他数据结构都不行，因为它们的对象标识即使保持不变，值也会改变。

最重要的是，在传递字典、列表或集合时，它们可能会在其他上下文中被意料之外地改变。这种问题非常难以调试。可修改的默认参数就是个经典的例子：

def add_bar(items=[]):  
 items.append('bar')  
 return items  
l = add_bar() # l is ['bar']  
l.append('foo')  
add_bar() # returns ['bar', 'foo', 'bar'] 

字典、集合和列表很强大、效率很高、非常 Python，而且非常有用。写代码时完全不使用它们是不明智的。但即使如此，我永远会在默认参数的位置使用元组或 None（代替空字典或空列表），并且在缺乏足够的防御代码的情况下，避免将可修改的数据结构在不同的上下文中传递。

减少类的使用

类（及其实例）的可修改性是把双刃剑。随着写的 Python 代码越来越多，，我开始倾向于仅在绝对必要时才使用类，而且我几乎从不使用可修改的类属性。对于那些高度面向对象的语言（如 Java）的程序员来说这一点可能很难做到，但许多其他语言中在类层面完成的东西，在 Python 可以在模块层面完成。例如，如果需要将函数或常量或命名空间分组，那么可以把它们一起放到另一个 .py 文件中。

我经常看到一些类的目的是保存几个命名变量的值，这种情况下 namedtuple（其类型是 typing.NamedTuple）就足够，而且还是不可改变的。

from collections import namedtuple  
VerbTenses = namedtuple('VerbTenses', ['past', 'present', 'future'])  
# versus  
class VerbTenses(object):  
 def __init__(self, past, present, future):  
 self.past = past,  
 self.present = present  
 self.future = future 

如果确实需要状态的来源，而且多个视图都需要改变该状态，那么类是绝佳的选择。此外，与静态方法相比，我更倾向于单例纯函数，这样它们能在其他上下文中组合使用。

（编辑：ASP站长网）