在函数式-面向对象混合语言中，经常会遇到一种常见的模式，这个模式需要一个名称，即使用柯里化参数列表和按名参数创建控制抽象。

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

产生的效果是：

command (expr) {
  block
}

鉴于其他一些"edgy"（前卫的）名称，我们可以称之为"Do Me"模式吗？

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

这看起来类似于Scala Wiik上称之为"loan"模式的东西：scala.sygneca.com/patterns/loan

设计模式是用于解决特定问题的通用解决方案。在函数式和面向对象混合语言中，由于语言特性的限制和不足，可能需要对现有的设计模式进行修改或重新设计。这就是“面向函数-面向对象混合语言的设计模式”这个问题的出现原因。

在论文《可扩展组件抽象》（Martin Odersky; Matthias Zenger）中，作者提出了三个可重用组件的构建要素：抽象类型成员、显式自类型和模块化混入组合。通过重新审视几个设计模式（发布/订阅、主题/观察者、上下文/组件），作者试图理解并阐明哪些语言构造对于实现可扩展和动态组件系统至关重要。

抽象类型成员是一种特殊类型的成员，可以在具体的子类中进行具体化。显式自类型是指一个类可以指定它的超类，从而限制该类只能被特定类型的对象继承。模块化混入组合是一种将多个组件合并到一个组件中的方法，以实现代码的复用和灵活性。

通过重新审视发布/订阅、主题/观察者和上下文/组件等设计模式，作者展示了如何利用抽象类型成员、显式自类型和模块化混入组合来实现这些模式，从而实现可扩展和动态的组件系统。这些语言构造的使用使得组件之间的通信和协作更加灵活和可扩展。

总结起来，面向函数-面向对象混合语言的设计模式的出现原因是为了解决在这种语言中实现可扩展和动态组件系统所面临的挑战。通过使用抽象类型成员、显式自类型和模块化混入组合等语言构造，可以重新设计和修改现有的设计模式，以适应混合语言的需求。这些语言构造的使用可以使得组件系统更加灵活、可扩展和动态。

混合函数式-面向对象语言的设计模式

设计模式的出现原因：

- 需要解决类组合的问题，即为了实现某个功能，需要将多个类组合在一起。这种情况下，Stackable Trait和装饰器模式类似，但是Stackable Trait是为了实现类组合而不是对象组合。

- 需要提供服务给客户端，客户端可以通过混入或导入的方式访问这些服务。Selfless Trait可以解决这个问题。

解决方法：

- Stackable Trait模式：通过使用trait来实现类的组合，trait可以被其他类混入，从而实现类的功能组合。

- Selfless Trait模式：通过使用trait来提供服务，客户端可以通过混入或导入trait来访问这些服务。

- Type safe builder模式：在Scala中实现类型安全的builder模式，可以避免运行时错误。

- Independently Extensible Solutions to the Expression Problem：解决表达式问题的独立可扩展解决方案，类似于可扩展组件抽象，处理类似的问题（如访问者模式）。

- Deprecating the Observer Pattern：观察者模式的替代方案。

- Scala中对Haskell类型类的模拟：将Haskell类型类视为设计模式。

- 各种monad：用于处理副作用和异步计算等问题。

以上是一些在混合函数式-面向对象语言中常用的设计模式。