41
votes

Is there already any collection of best practices for languages like Scala?

I've found a work on design patterns for functional languages, Design patterns for functional strategic programming. There's GoF design patterns for OO languages. But are there any patterns for functional-OO hybrids? All I've seen is this list. What is known?

5
The last link is broken (near "All I've seen").Peter Mortensen

5 Answers

20
votes

Two patterns from Bill Venners; I think both are heavily used in ScalaTest:

Stackable Trait (similar in structure to the decorator pattern, except it involves decoration for the purpose of class composition instead of object composition).

Selfless Trait (allows library designers to provide services that their clients can access either through mixins or imports).

Type safe builder

Independently Extensible Solutions to the Expression Problem - just like the "Scalable Component Abstraction", it's not a pattern catalog, but it also deals with similar problems (e.g. the Visitor pattern)

Deprecating the Observer Pattern - an alternative to the Observer.

We can also consider the Scala emulation of Haskell type classes a design pattern. The first description (that I could find at least) is in Poor Man's Type Classes. Quite some blog entries are also available with this topic.

And I think I'm not completely wrong if I also mention the various monads. You can find a lot of resources dealing with them.

12
votes

While not directly a design pattern catalog itself, the paper "Scalable Component Abstractions" (Martin Odersky; Matthias Zenger) examines three building blocks for reusable components:

  • abstract type members,
  • explicit selftypes, and
  • modular mixin composition.

And it revisits several design pattern (publish/subscribe, subject/observer, Context/Component) to illustrate and understand what language constructs are essential to achieve systems of scalable and dynamic components.

5
votes

One frequently observed pattern, which badly needs a name, is creating control abstractions with curried parameter lists and by-name parameters.

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

yielding

command (expr) {
  block
}
4
votes

In as much as any Object-Functional language is quickly going to acquire an actor library, a large number of actor-based patterns probably qualify for this question. Almost any of the patterns in Bob Martin's Enterprise Integration Patterns is recastable in terms of actors, with patterns like Load Balancer, Message Filter, Content-Based Router, and Content Enricher being especially common in systems architected around coarse-grained actors.

3
votes

Closely related, you might want to explore data structures as defined in purely functional (or hybrid functional) languages. For one, the ability to treat functions as first-class values make some patterns (like visitor, template method or decorator) unnecessary in some (not all) contexts. Secondly, data structures (and the algorithms that operate on them) are either the plumbing for design patterns, or present certain problems that design patterns attempt to address, see Wikipedia article Purely functional.

Better yet, I'd refer you to Okasaki's thesis on purely functional data structures.