函数世界中的一些经验主义者认为设计模式的概念有缺陷，在函数式编程中不需要。在模式 的狭义解释下该观点可能成立，但这是一个更多关于语义而非使用的论点。设计模式的概念 （针对常见问题的指定编目解决方案）是合理的。但是，模式有时在不同的范式下以不同的形式出现。因为构建块和问题解决方法在函数世界中是不同的，一些传统的 Gang of Four 模式（参阅 参考资料 ）消失了，而其他模式存在问题，但解决问题的方式大相径庭。本期和下一期将研究一些传统的设计模式，并以函数式思维从全新角度来思考它们。
在函数编程领域，传统设计模式通常以三种方式之一表现：
- 模式由语言吸收。
- 模式解决方案仍然存在于函数范式中，但是实现细节有所不同。
- 解决方案使用其他语言或范式缺乏的功能实现。（例如，许多使用元编程的解决方案简洁且优雅，但无法通过 Java 实现。）
我会依次研究这三种情况，在本期中从一些熟悉的模式入手，大部分模式全部或部分地纳入现代语言。
局部套用 (Currying) 是许多函数语言的一种特性。它是以数学家 Haskell Curry 的名字命名的（Haskell 编程语言也是以该数学家命名），能够对多参数函数进行转换，以便将它用作一串单参数函数进行调用。与此密切相关的是部分应用 (partial application) ，该技术可以将固定值分配给函数的一个或多个参数，从而生成另一个更小的元数 (arity) 函数（元数是函数参数的个数）。我在 “函数式思维：运用函数式思维，第 3 部分 ” 中讨论过这两种技术。
在设计模式上下文中，局部套用充当一个函数工厂。函数式编程语言中的一个常见特性是一等（first-class）（或高阶）函数，它允许函数充当任何其他数据结构。多亏这一特性，我可以轻松创建基于一些条件返回其他函数的函数，这就是工厂的精髓。例如，如果您有一个将两个数字相加的通用函数，您可以将局部套用用作一个工厂来创建总是将其参数加 1 的函数，即一个增量器，如清单 1 所示，使用 Groovy 语言实现：
def adder = { x, y -> return x + y } def incrementer = adder.curry(1) println "increment 7: ${incrementer(7)}" // prints "increment 7: 8" |
在 清单 1 中，我将第一个参数局部套用为 1 ，返回一个接受单一参数的函数。本质上，我创建了一个函数工厂。
当您的语言本机支持这种行为时，它往往被用作其他大小对象的构建块。例如，看看如清单 2 所示的 Scala 示例：
object CurryTest extends Application { def filter(xs: List[Int], p: Int => Boolean): List[Int] = if (xs.isEmpty) xs else if (p(xs.head)) xs.head :: filter(xs.tail, p) else filter(xs.tail, p) def dividesBy(n: Int)(x: Int) = ((x % n) == 0) val nums = List(1, 2, 3, 4, 5, 6, 7, 8) println(filter(nums, dividesBy(2))) println(filter(nums, dividesBy(3))) } |
清单 2 中的代码是 Scala 文档中递归和局部套用的示例之一（参阅 参考资料 ）。filter() 方法通过 p 参数以递归的方式过滤一个整数列表。p 是一个谓词函数 ，函数领域中用于布尔函数的一个常见术语。filter() 方法检查看列表是否为空，如果为空，就直接返回；否则它通过谓词检查列表中的第一个元素（xs.head ），以确定是否应将其包含在过滤的列表中。如果它通过谓词测试，返回的就是一个新列表，其头在前面，过滤的尾部作为剩余部分。如果第一个元素没有通过谓词测试，返回的就只是列表的已过滤剩余部分。
从模式角度来看 清单 2 中比较有趣的是在 dividesBy() 方法中对局部套用的 “随意” 使用。注意，dividesBy() 接受两个参数，并根据第二个参数是否均衡地分为第一个参数，返回 true 或 false 。但是，当该方法被作为 filter() 方法调用的一部分被调用时，它只在具有一个参数的情况下被调用，调用结果是一个局部套用过的函数，然后该函数被用作 filter() 方法中的谓词。
本例展示模式在函数式编程中表现的前两种方式，我在本文开始列出过它们。首先，局部套用被构建到语言或运行时中，因此函数工厂的概念是生来就有的，且不需要额外的结构。其次，它展示了我对不同实现的观点。如 清单 2 那样使用局部套用可能从来不会在传统的 Java 编程员身上发生；我们从未真正有过可移植代码，当然也从未想过从更通用的函数构建特定函数。事实上，在这里大部分的开发人员不会想到使用一个设计模式，因为从一个更通用的方法创建一个特定的 dividesBy() 方法似乎是一个小问题，而设计模式（很大程度上依赖于结构来解决问题，因而需要大量开销来实现）似乎是一个针对大问题的解决方案。按照本来意图使用局部套用不会证明一个特殊名称的程序的合理性，除了它已经拥有的名称。
一等函数大大简化了许多常用的设计模式。（命令设计模式甚至消失了，因为您不再需要一个针对可移植功能的对象包装器。）
一等函数使模板方法设计模式（参阅 参考资料 ）更易于实现，因为它们能够移除可能不需要的结构。模板方法定义一个方法中算法的框架，把一些步骤委托给子类，并强制他们在不更改算法结构的情况下定义这些步骤。模板方法的典型实现如清单 3 所示，使用 Groovy 实现：
abstract class Customer { def plan def Customer() { plan = [] } def abstract checkCredit() def abstract checkInventory() def abstract ship() def process() { checkCredit() checkInventory() ship() } } |
在 清单 3 中，process() 方法依赖于 checkCredit() 、checkInventory() 和 ship() 方法，其定义必须由子类提供，因为它们是抽象方法。
由于一等函数可充当任何其他数据结构，我可以使用代码块重新定义 清单 3 中的示例，如清单 4 所示：
class CustomerBlocks { def plan, checkCredit, checkInventory, ship def CustomerBlocks() { plan = [] } def process() { checkCredit() checkInventory() ship() } } class UsCustomerBlocks extends CustomerBlocks{ def UsCustomerBlocks() { checkCredit = { plan.add "checking US customer credit" } checkInventory = { plan.add "checking US warehouses" } ship = { plan.add "Shipping to US address" } } } |
在 清单 4 中，算法中的步骤只是类的属性，像任何其他属性一样是可分配的。在这个示例中，语言特性主要地吸收实现细节。将这一模式看作一个问题的解决方案（把步骤委派给后续的处理程序）仍然很有用，不过实现起来比较简单。
两种解决方案不是等同的。在 清单 3 中的 “传统” 模板方法示例中，抽象类需要子类来实现依赖的方法。当然，子类可能仅创建一个空的方法体，不过抽象方法定义形成一种文档，提醒 subclasser 将其考虑在内。另一方面，死板的方法声明可能不适合于需要更多灵活性的情景中。例如，我可以创建我的 Customer 类的一个版本，该类接受任何方法列表以供进行处理。
对代码块等功能的深度支持使语言更具有开发人员友好性。考虑这样一种情况，比如您想让 subclasser 跳过一些步骤。Groovy 有一种特殊的受保护访问运算符 (?. )，该运算符确保在调用一个对象的方法前该对象不为空。考虑清单 5 中的 process() 定义：
def process() { checkCredit?.call() checkInventory?.call() ship?.call() } |
在 清单 5 中，实现子类的任何人可以选择要将代码分配哪些子方法，保留其他方法为空。
一等函数简化的另一种流行设计模式是策略模式。策略定义一系列算法，封装每一种算法并使它们能够进行互换。它允许算法随使用它的客户不同而有所不同。一等函数使得构建和操作策略更简单。
用于计算产品数目的策略设计模式的一种传统实现如清单 6 所示：
interface Calc { def product(n, m) } class CalcMult implements Calc { def product(n, m) { n * m } } class CalcAdds implements Calc { def product(n, m) { def result = 0 n.times { result += m } result } } |
在 清单 6 中，我为具有两个数目的产品定义了一个接口。我使用两个不同的具体类（策略）实现接口：一个使用乘法，另一个使用加法。为测试这些策略，我创建了一个测试用例，如清单 7 所示：
class StrategyTest { def listOfStrategies = [new CalcMult(), new CalcAdds()] @Test public void product_verifier() { listOfStrategies.each { s -> assertEquals(10, s.product(5, 2)) } } } |
如 清单 7 所示，两个策略都返回同一个值。将代码块用作一等函数，我可以降低上一个示例的复杂性。考虑乘方策略用例，如清单 8 所示：
@Test public void exp_verifier() { def listOfExp = [ {i, j -> Math.pow(i, j)}, {i, j -> def result = i (j-1).times { result *= i } result }] listOfExp.each { e -> assertEquals(32, e(2, 5)) assertEquals(100, e(10, 2)) assertEquals(1000, e(10, 3)) } } |
在 清单 8 中，我使用 Groovy 代码块直接定义了两个内联乘方策略。如 模板方法示例 中所示，我以简化繁。传统的方法强制围绕每个策略使用名称和结构，有时这是我们需要的。但是，注意，我建议对 清单 8 中的代码加入更严格的保护措施，鉴于我无法轻松绕过更传统的方法施加的限制，传统方法是一种动态与静态对比参数，而非函数式编程与设计模式对比的参数。
受一等函数影响的模式主要是语言吸收的模式示例。接下来，我要展示保持语义但又更改实现的一种模式。
享元 (Flyweight) 和内存化 (memoization)
享元模式是一种使用共享来支持大量细粒度对象引用的优化技术。您要保持对象池可用，为特定视图创建到该池的引用。享元使用一种规范对象（canonical object） 的思想，即一种表示该类型中所有其他对象的代表性对象。例如，您有一个特定的消费产品，产品的规范版本表示该类型的所有产品。在一个应用程序中，不要为每个用户创建一个产品列表，而要创建一个规范产品列表，每个用户拥有对他们产品列表的引用。
考虑清单 9 中建模计算机类型的类：
class Computer { def type def cpu def memory def hardDrive def cd } class Desktop extends Computer { def driveBays def fanWattage def videoCard } class Laptop extends Computer def usbPorts def dockingBay } class AssignedComputer { def computerType def userId public AssignedComputer(computerType, userId) { this.computerType = computerType this.userId = userId } } |
在这些类中，比方说为每个用户创建一个新的 Computer 实例是效率低下的，假定所有计算机具有相同的规格。一个 AssignedComputer 会将一种计算机与一个用户关联起来。
让该代码更高效的一种常见方式是将工厂和享元模式相结合起来。考虑生成规范计算机类型的单例工厂，如清单 10 所示：
class ComputerFactory { def types = [:] static def instance; private ComputerFactory() { def laptop = new Laptop() def tower = new Desktop() types.put("MacBookPro6_2", laptop) types.put("SunTower", tower) } static def getInstance() { if (instance == null) instance = new ComputerFactory() instance } def ofType(computer) { types[computer] } } |
ComputerFactory 类构建可能的计算机类型缓存，然后通过其 ofType() 方法交付适当的实例。这是一种传统的单例工厂，因为您使用 Java 编写它。
但是，单例也是一种设计模式（参阅 参考资料 ），它是运行时吸收模式的另一个好示例。考虑简化的 ComputerFactory ，其中使用 Groovy 提供的 @Singleton 注释，如清单 11 所示：
@Singleton class ComputerFactory { def types = [:] private ComputerFactory() { def laptop = new Laptop() def tower = new Desktop() types.put("MacBookPro6_2", laptop) types.put("SunTower", tower) } def ofType(computer) { types[computer] } } |
为测试工厂返回规范实例，我编写了一个单元测试，如清单 12 所示：
@Test public void flyweight_computers() { def bob = new AssignedComputer(ComputerFactory.instance.ofType("MacBookPro6_2"), "Bob") def steve = new AssignedComputer(ComputerFactory.instance.ofType("MacBookPro6_2"), "Steve") assertTrue(bob.computerType == steve.computerType) } |
跨实例保存常见信息是一个不错想法，这是我在涉足函数式编程时想保留的想法。但是，实现细节相当不同。这是在更改（更合适的说说是简化）实现时保留模式语义 的一个示例。
在 函数式思维：Groovy 中的函数式特性，第 3 部分 中，我介绍了内存化 特性，它能够构建到编程语言中，支持自动缓存递归的函数返回值。换言之，一个内存化函数支持运行时为您缓存值。Groovy 的最新版本支持内存化（参阅 参考资料 ）。考虑清单 13 中定义的函数：
def computerOf = {type -> def of = [MacBookPro6_2: new Laptop(), SunTower: new Desktop()] return of[type] } def computerOfType = computerOf.memoize() |
在 清单 13 中，规范类型在 computerOf 函数内定义。为了创建一个函数的内存化实例，我直接调用 Groovy 运行时定义的 memoize() 方法。
清单 14 显示对比两种方法调用的一个单元测试：
@Test public void flyweight_computers() { def bob = new AssignedComputer(ComputerFactory.instance.ofType("MacBookPro6_2"), "Bob") def steve = new AssignedComputer(ComputerFactory.instance.ofType("MacBookPro6_2"), "Steve") assertTrue bob.computerType == steve.computerType def sally = new AssignedComputer(computerOfType("MacBookPro6_2"), "Sally") def betty = new AssignedComputer(computerOfType("MacBookPro6_2"), "Betty") assertTrue sally.computerType == betty.computerType } |
最终结果是一样的，但注意实现细节却有着巨大差别。对于 “传统” 设计模式，我创建了一个新类来充当工厂，实现两个模式。对于函数版本，我实现了一个方法，然后返回了一个内存化版本。卸载缓存等细节到运行时意味着手写的实现不太可能失败。在本用例中，我保留了享元模式的语义，但具有一个非常简单的实现。
在本期中，我介绍了设计模式的语义在函数式编程中表现的三种方式。首先，它们可以被语言或运行时吸收。我使用工厂、策略、单例和模板方法模式展示了相关示例。其次，模式可保留其语义，但具有完全不同的实现；我展示了使用类和使用内存化的享元模式示例。第三，函数语言和运行时可以有完全不同的特性，从而支持它们以完全不同的方式解决问题。
在下一期，我将继续研究设计模式和函数式编程的交叉，并展示第三种方法的示例。
本文转载于developerWorks，原文在这里
4400
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
