函数OO混合语言的设计模式?

Bill Venners的两种模式;我认为这两种模式在scalatest中都被大量使用:

Stackable Trait (在结构上与装饰图案相似,只是为了类组合而不是对象组合而进行的装饰)。

Selfless Trait (允许库设计人员提供客户机可以通过mixin或imports访问的服务)。

Type safe builder

Independently Extensible Solutions to the Expression Problem -就像“可伸缩组件抽象”一样,它不是模式目录,但它也处理类似的问题(例如访问者模式)。

Deprecating the Observer Pattern -观察员的替代品。

我们也可以考虑 Haskell 类型类设计模式。第一个描述(至少我能找到)在 Poor Man's Type Classes . 这个主题还提供了相当多的博客条目。

如果我也提到各种单子的话,我想我不是完全错的。你可以找到很多资源来处理它们。

虽然不是直接的设计模式目录本身,但论文 Scalable Component Abstractions “(Martin Odersky;Matthias Zenger)检查了三个可重用组件的构建块:

• 抽象类型成员,
• 明确的自我类型,以及
• 模块化混音器组成。

它重新审视了几种设计模式(发布/订阅、主题/观察者、上下文/组件),以说明和理解什么语言结构对于实现可伸缩和动态组件系统至关重要。

一个经常观察到的模式,非常需要一个名称,它是用课程参数列表和按名称参数创建控制抽象。

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

顺从的

command (expr) {
  block
}

在任何对象函数语言很快就要获得一个参与者库的同时,大量基于参与者的模式可能也适合这个问题。几乎所有鲍勃·马丁的图案 Enterprise Integration Patterns 在参与者方面是可恢复的,负载均衡器、消息过滤器、基于内容的路由器和内容丰富器等模式在围绕粗粒度参与者架构的系统中尤其常见。

密切相关,您可能希望探索中定义的数据结构。 purely functional (或混合功能)语言。首先,将函数视为第一类值的能力使一些模式(例如 visitor , template method 或 decorator )在某些(不是所有)情况下是不必要的。第二,数据结构(以及操作它们的算法)要么是设计模式的管道,要么是设计模式试图解决的某些问题,见维基百科文章。 Purely functional .

更好的是,我建议你 Okasaki's thesis on purely functional data structures .