views:

1619

answers:

5

Is there already any collection of best practices for languages like Scala? I've found a work on design patterns for functional languages here. There's GoF design patterns for oo languages. But are there any patterns for functional-oo hybrids? All I've seen is this list. Does anyone know any more?

+11  A: 

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.

VonC
+12  A: 

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):
http://www.artima.com/scalazine/articles/stackable_trait_pattern.html

Selfless Trait (allows library designers to provide services that their clients can access either through mixins or imports):
http://www.artima.com/scalazine/articles/selfless_trait_pattern.html

Type safe builder:
http://blog.rafaelferreira.net/2008/07/type-safe-builder-pattern-in-scala.html

Independently Extensible Solutions to the Expression Problem - just like the "Scalable Component Abstraction" it's not a pattern catalog, but also deals with similar problems (e.g. the Visitor pattern)
http://www.scala-lang.org/docu/files/IC_TECH_REPORT_200433.pdf

Deprecating the Observer Pattern - an alternative to the Observer
http://infoscience.epfl.ch/record/148043/files/DeprecatingObserversTR2010.pdf

We can also consider the scala emulation of Haskell type classes a design pattern. First description (that I could find at least) is in Poor Man's Type Classes
http://lampwww.epfl.ch/~odersky/talks/wg2.8-boston06.pdf
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.

Sandor Murakozi
+5  A: 

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
}
Don Mackenzie
Given some of the other "edgy" names, how about the "Do Me" pattern?
Randall Schulz
By the way, I think we should be careful about terminology and in this case, this is not a curried *function*, but rather a *method* with multiple argument lists.
Randall Schulz
That looks similar to what the call the "loan" pattern on the Scala wiik: http://scala.sygneca.com/patterns/loan
David Holbrook
+4  A: 

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.

Dave Griffith
+3  A: 

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 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:

http://en.wikipedia.org/wiki/Purely_functional

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

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.64.3080

luis.espinal