函数设计模式,第 1 部分

      2020-09-16 10:32      JAVA开发
-->

系列内容:

此内容是该系列 # 部分中的第 # 部分: 函数式思维

https://www.ibm.com/developerworks/cn/views/global/libraryview.jsp?series_title_by=函数式思维敬请期待该系列的后续内容。

此内容是该系列的一部分:函数式思维

敬请期待该系列的后续内容。

关于本系列

本 系列 的目标是重新调整您对函数思维的认识,帮助您以全新的方式看待常见问题,并提升您的日常编码能力。本系列文章将探讨函数编程概念、允许在 Java™ 语言中进行函数式编程的框架、在 JVM 上运行的函数编程语言,以及语言设计的未来方向。本系列面向那些了解 Java 及其抽象工作原理,但对函数语言不甚了解的开发人员。

函数世界中的一些经验主义者认为设计模式的概念有缺陷,在函数式编程中不需要。在模式 的狭义解释下该观点可能成立,但这是一个更多关于语义而非使用的论点。设计模式的概念(针对常见问题的指定编目解决方案)是合理的。但是,模式有时在不同的范式下以不同的形式出现。因为构建块和问题解决方法在函数世界中是不同的,一些传统的 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() 接受两个参数,并根据第二个参数是否均衡地分为第一个参数,返回 truefalse。但是,当该方法被作为 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. 以更低的复杂性测试乘方
    @Testpublic 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. 测试规范类型
    @Testpublic 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. 对比方法
    @Testpublic 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}

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

    结束语

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

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