Back to Questions
3.6k
views4
comments
F# Design Patterns for the Java Programmer
f#functionaljava

More or less, I am a Java programmer trying to learn F#. In this thread, I posted some code, and jdh30 was nice enough to show how it could written better using F# idioms. It got me thinking about how I don't have a functional programming mindset at all, all of my F# programs look like Java with a little different syntax, and I'm not really exploiting functional programming to its full potential.

The first thing I noticed about F# tutorials in general is that none of them say a single word about common design patterns in F# or functional programming. To me, coming from Java and C#, is just bizarre; I can't imagine that there are no tried and tested ways of writing applications. The only reference to design patterns I've found on Google is this short blurb:

Functional languages are extremely expressive. In a functional language one does not need design patterns because the language is likely so high level, you end up programming in concepts that eliminate design patterns all together.

Really? I'll believe it when I see it.

I want to repost the code from the thread mentioned at the top of this post, and jdh30's refactored version:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

#light
open System

type TransactionItem(name, id) = class
    let mutable _isProcessed = false
    
    member this.Name : string = name
    member this.ID : int = id
    member this.IsProcessed
        with get() = _isProcessed
        and set(value) = _isProcessed <- value       
end

type IProcess = interface
    abstract Process : TransactionItem -> unit
end

type MockProcessor() = class
    interface IProcess with
        member this.Process (item) = item.IsProcessed <- true
    end
end

type TransactionProcessor(processor : IProcess) = class
    member this.Process (items) = items |> Seq.iter processor.Process
end

let PrintItems (items : TransactionItem list) =
    items |> Seq.iter (fun x ->
        Console.WriteLine("Name: {0}\n" +
            "ID: {1}\n" +
            "IsProcessed: {2}\n", x.Name, x.ID, x.IsProcessed))


let main() =
    let items = 
        [ new TransactionItem("Juliet", 1);
            new TransactionItem("Bob", 2);
            new TransactionItem("Jack", 3) ]

    let transProcessor = new TransactionProcessor(new MockProcessor())
    
    Console.WriteLine("Before:")
    PrintItems items
    
    transProcessor.Process(items)
    
    Console.WriteLine("After:")
    PrintItems items
    
    Console.ReadLine()
    
main()
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

#light

type TransactionItem = { name: string; id: int; is_processed: bool }

let item(name, id) = { name=name; id=id; is_processed=false }

let mock_processor item = { item with is_processed = true }

let print items =
    for x in items do
        printf "Name: %s\nID: %d\nIsProcessed: %b\n" x.name x.id x.is_processed

let items = Seq.map item ["Juliet", 1; "Bob", 2; "Jack", 3 ]

printf "Before:\n"
print items

let processeditems = Seq.map mock_processor items

printf "After:\n"
print processeditems

stdin.ReadLine()

(Note: I had to make a few minor changes to jdh30's code to make it compile)

My code is 53 lines, its written in a Java/C#-like style. jdh30's is 23 lines, its written more like F#.

Is jdh30's code really the best way to write the program above?

What if my processor did something significantly complicated, for example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

type RealProcessor() = class
    let getEmailAddress id =
        let comm =
            new SqlCommand("SELECT email_addr FROM Users WHERE ID = @id",
                new SqlConnection("some connection string") )
        try
            comm.Connection.Open()
            comm.Parameters.AddWithValue("@id", id) |> ignore
            comm.ExecuteScalar().ToString()
        finally
            match comm.Connection.State with
            | ConnectionState.Open -> comm.Connection.Close()
            | _ -> ()
        
    interface IProcess with
        member this.Process (item) =
            match item.IsProcessed with
            | true ->
                let emailAddress = getEmailAddress item.ID
                
                let mail =
                    new System.Net.Mail.MailMessage("<A href="mailto:juliet@website.com">juliet@website.com</A>", 
                        emailAddress,
                        "Your order has been processed",
                        item.Name + ", thank you for your order.")
                
                let smtp = new System.Net.Mail.SmtpClient()
                smtp.Send(mail)
                
                item.IsProcessed <- true
            | false -> ()
    end        
end

The RealProcessor is more than just a fancy map. It reads from a database and sends an email; if I wanted to, I could have it insert items into a database, move files around on disk, etc. "Processing an item" can actually involve a lot of work. Of course, when I'm writing unit tests, I don't want to touch the database or send email to people, I just want to keep it simple; that's why I have a RealProcessor and MockProcessor class which both implement the same interface.

The Java-like pattern above is a dependency injection pattern, so that I can use MockProcessor in my unit tests and use my RealProcessor in production. What is the equivalent way of implementing this type of pattern in F#? Or is there a totally different functional way of writing this kind of program?

.

Hello, Juliet.

1.\ There is nice paper by Peter Norvig: Design patterns in Dynamic Programming

2.\ Many design patterns (DP) are created to minimize errors at desing phase of software creation. For OO world those errors and troubles commonly linked to objects state, identity and class decomposition. In fact, OO designer ought to solve two tasks at one time: algorithmic decomposition and state/hierarchy decomposition.
For FP world you can solve those tasks independently. So, much of classic GoF DP are not so nice for FP world. Of course, you can train your sense of FP style by reading F#/Ocaml books and code snippets.

3.\ If you want to quickly destabilize your point of view to DP, i can recommend to find Haskell tutorial with clear description of the type classes, class exemplars and related Prelude parts (i don't remember concrete one, but www.haskell.org contains page with links to many nice tutorials).

By on 7/10/2008 12:21 PM ()

Hi Juliet,

You are now asking the correct questions!

There are certainly many patterns encountered in functional programming but nobody has really tried to collate them into a single set of design patterns. Consequently, they are not referred to as <i>design patterns<i>. Also, much of the literature on this predates the relatively recent invention of "design patterns" in OOP. The article that you cited which states that OO design patterns are obsolete in functional languages does have a strong point though. Most so-called "design patterns" are nothing more than work arounds for the deficiencies of OOP. Many of those deficiencies are simply not present with functional programming and, consequently, the work arounds are no longer of value. However, there are a precious few genuinely paradigm-agnostic design patterns (such as model-view-controller) that do persist with functional programming. Although the literature on functional programming rarely describes "design patterns" this is largely because they are not explicitly recognised and named as such. I would say that there are many well known functional design patterns: <UL><li>Using accumulator arguments when converting functions into tail recursive form.</LI><li>Continuation passing style.</LI><li>Combinators and, in particular, parser combinators.</LI><li>Untying the recursive knot via parameterization.</LI><li>Unfold.</LI><li>...</LI></UL> Both my (unpublished) book <A href="http://www.ffconsultancy.com/products/fsharp_for_scientists/?hub">F# for Scientists</A> and our <A href="http://www.ffconsultancy.com/products/fsharp_journal/?hub">F#.NET Journal</A> articles have already addressed functional design patterns specifically in F#. The recent article <A href="http://ocamlnews.blogspot.com/2008/06/tricks-with-recursion-knots-modules-and.html">Tricks with recursion: knots, modules and polymorphism</A> from our <A href="http://www.ffconsultancy.com/products/ocaml_journal/?hub">OCaml Journal</A> may also be of interest. Regarding your particular code here, I think the answers to your questions should be obvious. You have a class that implements an interface that defines a single function. That is nothing more than a reinvention of a closure from functional programming. So forget about all of that and just pass a function around. You ask what happens when RealProcess gets more complicated and the answer is that nothing changes because (as you decreed) your processor is still necessarily represented entirely by a single function. This is often true and is precisely why functional programming is so constructive (excuse the hillarious pun). There are situations where ML-style functional and object oriented programming have different characteristics and you must learn when to choose between them (or use a mixture of both, if necessary). The advantage of F# is that you have both completely at your disposal. This should lead you onto an obvious next question: for what applications is F# most useful? Cheers, Jon Harrop.

By on 7/7/2008 6:11 PM ()

Hi Julient,

Functional languages allow you to "capture design patterns" as functions, that is commonly repeated bits of code can rewritten as one function just leaving wholes where ever a bit of code is different. For example the gang of four's iterator pattern is simply a List.iter function in F#. In FP we generally call this abstraction of control flow and I wrote a blog post about this a little while ago: [link:www.strangelights.com]

Higher level design patterns like depency injection are still important and .NET has serval different depenancy injection containers, most of which are liberally inspired by java depency injection containers, all of which can be used with F#. Just google for spring .NET or castle project for more information on this.

Cheers,
Rob

By on 7/7/2008 12:43 AM ()

Hi Juliet,

You are iterating towards good F# design, which is usually a mix of FP and OO. You should also feel free to use your existing OO patterns, many of which are highly applicable to F# and indeed "look lovely" when captured in idomatic F#. My recommendation as people learn F# is to "change one variable at a time": you're learning a new language, so it's OK to keep your existing design patterns and gradually learn how they may simplify.

An object as simple as IProcess would typically be modelled as a function 

1
2
3
4

 

type Processor = (TransactionItem -> unit)

You wouldn't need to change this just because any particular Process does something complex. For mocking it does indeed look like you're just switching your code to a simpler processing function

1
2
3
4
5
6
7
8

 

let RealProcessor(item:TransactionItem) = <lots of code>

let MockProcessor (item: TransactionItem) = item.Processed <- true

let Processor = if testing then MockProcessor else RealProcessor

If the actual behaviour of individual processing functions changes when mocking then just pass the mocking flag in as a parameter:

1
2
3
4

 

type Processor = (bool * TransactionItem -> unit)

So, when should you use objects richer than functions? Very often. You would typically switch to using an interface when your notion of a "Processor" becomes more complex. For example it might

  • report partial progress by raising an event (though that could equally be modelled by passing the event to trigger in as a parameter)
  • it might support cancellation (though in this case you could also change the return type "unit" to be an ICancallable object)
  • etc.
By on 7/7/2008 7:25 AM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper