:::: MENU ::::
Browsing posts in: Javascript

Functional programming in Javascript and F#

During June 2011 I presented a session at the SPA2011 conference in London, UK.

My session was a hands on introduction to functional programming techniques with code samples in Javascript and F#. The focus on the session was to get peopling thinking about first class functions; and the techniques they enable to simplify and increase readability of code when solving certain classes of problems.

The code samples can be found at:

An online/executable version of the Javascript code is at http://functional-javascript.davidlaing.com.

Judging by the feedback I received, the session went very well. People seemed to like the hands-on format of the session; and just being left alone for a while to learn something at their own pace.


Implementing the strategy pattern without an explosion of classes – part 3 of ??

I feel uncomfortable when I see large switch statements. I appreciate how they break the Open Closed Principle. I have enough experience to know that they seem to attract extra conditions & additional logic during maintenance, and quickly become bug hotspots.

A refactoring I use frequently to deal with this is Replace Conditional with Polymorphism; but for simple switches, its always seemed like a rather large hammer.

Take the following simple example that performs slightly different processing logic based on the credit card type:

Its highly likely that the number of credit card types will increase; and that the complexity of processing logic for each will also increase over time. The traditional application of the Replace Conditional with Polymorphism refactoring gives the following:

This explosion of classes containing almost zero logic has always bothered me as quite a lot of boilerplate overhead for a relatively small reduction in complexity.

Consider however, the functional approach to the same refactoring:

Here we have obtained the same simplification of the switch statement; but avoided the explosion of simple classes. Whilst strictly speaking we are still violating the Open Closed Principle; we do have a collection of simple methods that are easy to comprehend and test. It’s worth noting that when our logic becomes very complex; converting to the OO Strategy pattern becomes a more compelling option. Consider the case when we include a collection of validation logic for each credit card:

In this case the whole file starts to feel too complex to me; and having the logic partitioned into separate strategy classes / files seems more maintainable to me.

To conclude then, the fact that languages treat functions as first class constructs, gives us the flexibility to use them in a “polymorphic” way; where our “interface” is the function signature.

And for some problems, like a refactoring a simple switch statement; I feel this gives us a more elegant solution.


Learning functional Javascript through Koans

Given how Javascript interpreters are improving in leaps and bounds; and that it seems to be the only language that will be supported by all web devices; its time to for me to revive my Javascript skilz. Fortunately the tooling has improved greatly; Eclipse 3.6 for Web Developers and JsTestDriver bring a refactoring and a unit test runner to Javascript development.

Interestingly, Javascript seems to have more functional than object orientated characteristics; so it seems reasonable to learn it wearing my functional hat.

I’ve been enjoying learning Ruby syntax via RubyKoans – little tests that teach you syntax and convention as you make them pass

I though I’d create a similar set of Functional Javascript Koans to help refresh my Javascript skills.

Its a bit rough; so please fork and contibute back improvements.
https://github.com/mrdavidlaing/javascript-koans