函数式思维: 函数设计模式，第 1 部分

最新推荐文章于 2024-01-28 18:08:49 发布

Neo_Wu

最新推荐文章于 2024-01-28 18:08:49 发布

阅读量778

点赞数

分类专栏：设计模式

设计模式专栏收录该内容

25 篇文章 0 订阅

订阅专栏

模式在函数世界中的表现方式

与人们的普遍看法相反，设计模式存在于函数式编程中，不过它们有时在外观和行为上不同于其面向对象的模式。在本期的函数式思维中，Neal Ford 探究了模式在函数范式中的表现方式，展示了各种解决方案的不同之处。

查看本系列更多内容 | 0 评论：

Neal Ford, 软件架构师, ThoughtWorks Inc.

2012 年 3 月 31 日

内容

函数世界中的一些经验主义者认为设计模式的概念有缺陷，在函数式编程中不需要。在模式的狭义解释下该观点可能成立，但这是一个更多关于语义而非使用的论点。设计模式的概念（针对常见问题的指定编目解决方案）是合理的。但是，模式有时在不同的范式下以不同的形式出现。因为构建块和问题解决方法在函数世界中是不同的，一些传统的 Gang of Four 模式（参阅参考资料）消失了，而其他模式存在问题，但解决问题的方式大相径庭。本期和下一期将研究一些传统的设计模式，并以函数式思维从全新角度来思考它们。

在函数编程领域，传统设计模式通常以三种方式之一表现：

模式由语言吸收。
模式解决方案仍然存在于函数范式中，但是实现细节有所不同。
解决方案使用其他语言或范式缺乏的功能实现。（例如，许多使用元编程的解决方案简洁且优雅，但无法通过 Java 实现。）

我会依次研究这三种情况，在本期中从一些熟悉的模式入手，大部分模式全部或部分地纳入现代语言。

工厂和局部套用（currying）

局部套用 (Currying) 是许多函数语言的一种特性。它是以数学家 Haskell Curry 的名字命名的（Haskell 编程语言也是以该数学家命名），能够对多参数函数进行转换，以便将它用作一串单参数函数进行调用。与此密切相关的是部分应用 (partial application)，该技术可以将固定值分配给函数的一个或多个参数，从而生成另一个更小的元数 (arity) 函数（元数是函数参数的个数）。我在 “函数式思维：运用函数式思维，第 3 部分” 中讨论过这两种技术。

在设计模式上下文中，局部套用充当一个函数工厂。函数式编程语言中的一个常见特性是一等（first-class）（或高阶）函数，它允许函数充当任何其他数据结构。多亏这一特性，我可以轻松创建基于一些条件返回其他函数的函数，这就是工厂的精髓。例如，如果您有一个将两个数字相加的通用函数，您可以将局部套用用作一个工厂来创建总是将其参数加 1 的函数，即一个增量器，如清单 1 所示，使用 Groovy 语言实现：

清单 1. 局部套用作为函数工厂

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 示例：

清单 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() 方法似乎是一个小问题，而设计模式（很大程度上依赖于结构来解决问题，因而需要大量开销来实现）似乎是一个针对大问题的解决方案。按照本来意图使用局部套用不会证明一个特殊名称的程序的合理性，除了它已经拥有的名称。

回页首

一等函数（First-class）和设计模式

一等函数大大简化了许多常用的设计模式。（命令设计模式甚至消失了，因为您不再需要一个针对可移植功能的对象包装器。）

模板方法

一等函数使模板方法设计模式（参阅参考资料）更易于实现，因为它们能够移除可能不需要的结构。模板方法定义一个方法中算法的框架，把一些步骤委托给子类，并强制他们在不更改算法结构的情况下定义这些步骤。模板方法的典型实现如清单 3 所示，使用 Groovy 实现：

清单 3. 模板方法的 “标准” 实现

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 所示：

清单 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() 定义：

清单 5. 添加对代码块调用的保护

def process() {
  checkCredit?.call()
  checkInventory?.call()        
  ship?.call()
}

在清单 5 中，实现子类的任何人可以选择要将代码分配哪些子方法，保留其他方法为空。

策略

一等函数简化的另一种流行设计模式是策略模式。策略定义一系列算法，封装每一种算法并使它们能够进行互换。它允许算法随使用它的客户不同而有所不同。一等函数使得构建和操作策略更简单。

用于计算产品数目的策略设计模式的一种传统实现如清单 6 所示：

清单 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 所示：

清单 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 所示：

清单 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 中建模计算机类型的类：

清单 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 所示：

清单 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 所示：

清单 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 所示：

清单 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 中定义的函数：

清单 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 显示对比两种方法调用的一个单元测试：

清单 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
}

最终结果是一样的，但注意实现细节却有着巨大差别。对于 “传统” 设计模式，我创建了一个新类来充当工厂，实现两个模式。对于函数版本，我实现了一个方法，然后返回了一个内存化版本。卸载缓存等细节到运行时意味着手写的实现不太可能失败。在本用例中，我保留了享元模式的语义，但具有一个非常简单的实现。

回页首

结束语

在本期中，我介绍了设计模式的语义在函数式编程中表现的三种方式。首先，它们可以被语言或运行时吸收。我使用工厂、策略、单例和模板方法模式展示了相关示例。其次，模式可保留其语义，但具有完全不同的实现；我展示了使用类和使用内存化的享元模式示例。第三，函数语言和运行时可以有完全不同的特性，从而支持它们以完全不同的方式解决问题。

在下一期，我将继续研究设计模式和函数式编程的交叉，并展示第三种方法的示例。

参考资料

学习

The Productive Programmer（Neal Ford，O'Reilly Media，2008 年）：Neal Ford 的新书讨论了帮助您提高编码效率的工具和实践。
Design Patterns: Elements of Reusable Object-Oriented Software（Erich Gamma 等人，Addison-Wesley，1994 年）：关于 Gang of Four 在设计模式方面的经典之作。
Design Patterns in Dynamic Languages：Peter Norvig 例证了强大的语言（比如函数语言）对设计模式具有更少需求。
Groovy：Groovy 是一种多范式 JVM 语言，其语法与 Java 非常接近。其高级特性包括许多函数式编程元素的增加。
Scala：Scala 是一种现代函数编程语言，适用于 JVM。
面向 Java 开发人员的 Scala 指南：通过 Ted Neward 撰写的 developerWorks 系列文章深入了解 Scala。
模板方法模式：模板方法是一种著名的 Gang of Four 设计模式。
单例模式：单例是另一种著名的 Gang of Four 设计模式。
Closure memoization：查看 Groovy 1.8 所添加的内存化特性的发布说明。
浏览技术书店，阅读有关这些主题和其他技术主题的图书。
developerWorks 中国网站 Java 技术专区：这里有数百篇关于 Java 编程各个方面的文章。

Neo_Wu

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
函数式思维: 函数设计模式，第 1 部分

模式在函数世界中的表现方式与人们的普遍看法相反，设计模式存在于函数式编程中，不过它们有时在外观和行为上不同于其面向对象的模式。在本期的函数式思维中，Neal Ford 探究了模式在函数范式中的表现方式，展示了各种解决方案的不同之处。查看本系列更多内容 | 0 评论：Neal Ford, 软件架构师, ThoughtWorks Inc.
复制链接

扫一扫