F# - Factory Method Design Pattern

Question

Below is my attempt at implementing the factory method design pattern using F# whilst trying to make it a little more functional (i.e. not a straight OO implementation). Below is what I came up with:

type ISkateBoard = abstract Model : unit -> string

type SkateBoard = 
| Roskopp 
| Peters
    interface ISkateBoard
        with member this.Model() = 
                match this with 
                | Roskopp-> "Rob Roskopp..."
                | Peters -> "Duane Peters..."

let assemble model : ISkateBoard =
    match model with
    | "Roskopp" -> Roskopp :> ISkateBoard
    | "Peters" -> Peters :> ISkateBoard
    | _ -> failwith "no such skateboard model.."

let SkateBoardFactory assemble model = assemble model

let SantaCruzFactory = SkateBoardFactory assemble

Is this an appropriate implementation of the factory method design pattern? Is the pattern used in real world F# applications?

Answer 1

I'm not sure to what extent is the factory method design pattern useful in functional programming. The goal of the pattern is to hide the creation of objects, so that you can work with just an abstract representation of the object.

• When you use F# in the functional way, you'll use concrete representations most of the time. For example, this gives you the ability to pattern match on the skateboard type.
• Of course, F# allows you to mix functional style with object-oriented style. For some purposes, OO style works well in F#. In that case, your approach looks quite reasonable.

Your factory method could take a concrete type (e.g. discriminated union) as an argument, instead of string. Then the task of the factory is to build abstract representation from the concrete representation:

// Abstract representation of the data
type ISkateBoard = 
  abstract Model : unit -> string

// Concrete representation of the data
type SkateBoard = 
  | Roskopp 
  | Peters

Now, a factory would be simply a function of type SkateBoard -> ISkateBoard. For example (using F# object expressions):

// Transform concrete representation to abstract representation 
let factory concrete = 
  match concrete with
  | Roskopp -> { new ISkateBoard with 
                   member x.Model() = "Rob Roskopp..." }
  | Peters -> { new ISkateBoard with 
                  member x.Model() = "Duane Peters..." }

I think that the benefit of this approach is that you can do some work on the concrete representation of the type (e.g. some calculation where you need pattern matching), but then you can use the factory to turn the concrete type into an abstract type.

This matches quite well with the usual approach in functional programming - you often use differenet representations of one data and transform between them (depending on which representation is better for a particular problem).

Answer 2

Along with what Tomas said, using concrete types allows you to sanitize your input and fail before you start creating objects with your factory.

type SkateBoard = 
    | Roskopp 
    | Peters
with 
    static member FromString = function
        | "Roskopp" -> Roskopp
        | "Peters" -> Peters            
        |  _ -> failwith "no such skateboard model.."

You will find a lot of design patterns from OO just go away in functional programming.

With SkateBoardFactory you create an extra function to execute your function.

let SkateBoardFactory assemble model = assemble model
let SantaCruzFactory = SkateBoardFactory assemble

You can simply assign the assemble because of first class functions.

let SantaCruzFactory = assemble