功能性OO混合语言的设计模式？

Posted 2023-03-15

【中文标题】功能性OO混合语言的设计模式？

【英文标题】：Design patterns for functional-OO hybrid languages?

【发布时间】：2011-03-06 07:13:12

【问题描述】：

是否已有针对 Scala 等语言的最佳实践集合？

我发现了一篇关于函数式语言设计模式的工作，Design patterns for functional strategic programming。 OO 语言有GoF 设计模式。但是函数式OO混合有什么模式吗？我所看到的只是this 列表。什么是已知的？

【问题讨论】：

最后一个链接坏了（在“All I've seen”附近）。

你可以看看pavelfatin.com/design-patterns-in-scala

【参考方案1】：

Bill Venners 的两种模式；我认为两者都在 ScalaTest 中大量使用：

Stackable Trait（在结构上类似于装饰器模式，不同之处在于它涉及的装饰是为了类组合而不是对象组合）。

Selfless Trait（允许库设计者提供他们的客户可以通过 mixins 或导入访问的服务）。

Type safe builder

Independently Extensible Solutions to the Expression Problem - 就像“Scalable Component Abstraction”一样，它不是模式目录，但它也处理类似的问题（例如访问者模式）

Deprecating the Observer Pattern - Observer 的替代品。

我们还可以将Haskell 类型类的Scala 模拟视为一种设计模式。第一个描述（至少我能找到）在 Poor Man's Type Classes。该主题还提供了相当多的博客条目。

如果我还提到各种单子，我认为我并没有完全错。你可以找到很多资源来处理它们。

【参考方案2】：

虽然不是直接的设计模式目录本身，但论文“Scalable Component Abstractions”（Martin Odersky；Matthias Zenger）研究了可重用组件的三个构建块：

抽象类型成员， 显式自我类型，以及 模块化mixin组成。

它重新审视了几种设计模式（发布/订阅、主题/观察者、上下文/组件），以说明和理解哪些语言结构对于实现可扩展和动态组件系统至关重要。

【参考方案3】：

一个经常观察到的非常需要名称的模式是使用柯里化参数列表和按名称参数创建控制抽象。

def command(expr: T)(block: => Unit) ...

屈服

command (expr) 
  block

【讨论】：

鉴于其他一些“前卫”的名字，“Do Me”模式怎么样？

顺便说一句，我认为我们应该注意术语，在这种情况下，这不是一个柯里化的函数，而是一个方法具有多个参数列表。

这看起来类似于 Scala wiik 上所谓的“贷款”模式：scala.sygneca.com/patterns/loan

【参考方案4】：

在任何对象函数语言都将很快获得演员库的情况下，大量基于演员的模式可能符合这个问题。 Bob Martin 的Enterprise Integration Patterns 中的几乎所有模式都可以在参与者方面进行重铸，负载均衡器、消息过滤器、基于内容的路由器和内容丰富器等模式在围绕粗粒度参与者构建的系统中尤为常见。

【参考方案5】：

密切相关，您可能想探索purely functional（或混合函数式）语言中定义的数据结构。一方面，将函数视为一等值的能力使得某些模式（如visitor、template method 或decorator）在某些（不是全部）上下文中是不必要的。其次，数据结构（以及在其上运行的算法）要么是设计模式的管道，要么是设计模式试图解决的某些问题，请参阅 Wikipedia 文章 Purely functional。

更好的是，我会把你推荐给Okasaki's thesis on purely functional data structures。