Exercises in Programming Style–Letterbox

You can become a serverless blackbelt. Enrol in my course Learn you some Lambda best practice for great good! and learn best practices for performance, cost, security, resilience, observability and scalability. By the end of this course, you should be able to make informed decisions on which AWS service to use with Lambda and how to build highly scalable, resilient and cost-efficient serverless applications.

NOTE : read the rest of the series, or check out the source code.

If you enjoy read­ing these exer­cises then please buy Crista’s book to sup­port her work.


Fol­low­ing on from the last post, we will look at the Letterbox style today.


Style 11 – Letterbox

You may also know this style as message passing, or SmallTalk style (or Objective-C for that matter). It was also what Alan Kay had in mind when he coined the term Object Orientation all those years ago ;-)





  • Larger problem is decomposed into things that make sense for the problem domain
  • Each thing is a capsule of data that exposes one single procedure, namely the ability to receive and dispatch messages that are sent to it
  • Message dispatch can result in sending the message to another capsule


The things that we end up with in this style is very similar to that of the Things (or OOP) style from the last post:

  • DataStorageManager
  • StopWordsManager
  • WordFrequencyManager
  • WordFrequencyController

The difference here is that, each of these things exposes only a Dispatch method.


Let’s look at the DataStorageManager first, a faithful translation of Crista’s example would look like this:


Compared to the DataStorageManager implementation in the Things style, there are some notable differences:

  • we lose type safety as we have to combine init and words into a single Dispatch method
    • what ‘functionalities’ the things can provide is implied through the tagged arrays that the Dispatch logic is happy to accept
    • the return types have to be unified to obj
  • data has to be mutable
    • consequently words also has to become a function


Given the strongly typed nature of F# we also need to explicitly cast every result to obj. This, of course, is not an issue in dynamically typed languages such as SmallTalk and Python. But, we’re in F# so let’s make the type system work for us rather than against us.

We can easily unify the different messages a Thing can accept into a union type:


Whilst we could also add a union type for the results, such as:

    type DSManagerResult = Init of unit | Words of string[]

I don’t consider it to be much better because as a consumer of this API I still find it ambiguous. The signature Dispatch : DSManagerMessage -> DSManagerResult would suggest that you can always get either Init of unit or Words of string[] for any DSManagerMessage, which isn’t true.

If you know of a better way to add type safety to the return type in this case, please let me know via the comments section below.


Moving on to the StopWordsManager, we can apply the same approach:


And the same goes to the WordFrequencyManager:


And lastly, the WordFrequencyController:


in the init function here, we’ll initialize the various dependencies and instruct each to initialize accordingly:


in the run function, we’ll connect the various Things together by dispatching messages to them in a pipeline:


To get the answer, we’ll have to send some messages to an instance of WordFrequencyController:



Wait, all these message dispatching business look an awful lot like actors, couldn’t we have implemented the Things using F#’s mailbox processors instead?

There’s actually a subtle difference here in that actors are characterised by an internal message queue (which is outside the scope of the constraints here) and messages are sent asynchronously. If you’re a fan of mailbox processors then worry not, the Actor style comes later on in this series.


You can find the source code for this exer­cise here.

Liked this article? Support me on Patreon and get direct help from me via a private Slack channel or 1-2-1 mentoring.
Subscribe to my newsletter

Hi, I’m Yan. I’m an AWS Serverless Hero and the author of Production-Ready Serverless.

I specialise in rapidly transitioning teams to serverless and building production-ready services on AWS.

Are you struggling with serverless or need guidance on best practices? Do you want someone to review your architecture and help you avoid costly mistakes down the line? Whatever the case, I’m here to help.

Hire me.

Check out my new podcast Real-World Serverless where I talk with engineers who are building amazing things with serverless technologies and discuss the real-world use cases and challenges they face. If you’re interested in what people are actually doing with serverless and what it’s really like to be working with serverless day-to-day, then this is the podcast for you.

Check out my new course, Learn you some Lambda best practice for great good! In this course, you will learn best practices for working with AWS Lambda in terms of performance, cost, security, scalability, resilience and observability. We will also cover latest features from re:Invent 2019 such as Provisioned Concurrency and Lambda Destinations. Enrol now and start learning!

Check out my video course, Complete Guide to AWS Step Functions. In this course, we’ll cover everything you need to know to use AWS Step Functions service effectively. There is something for everyone from beginners to more advanced users looking for design patterns and best practices. Enrol now and start learning!

Are you working with Serverless and looking for expert training to level-up your skills? Or are you looking for a solid foundation to start from? Look no further, register for my Production-Ready Serverless workshop to learn how to build production-grade Serverless applications!

Find a workshop near you