Exercises in Programming Style–Letterbox

Yan Cui

I help clients go faster for less using serverless technologies.

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.


Whenever you’re ready, here are 4 ways I can help you:

  1. If you want a one-stop shop to help you quickly level up your serverless skills, you should check out my Production-Ready Serverless workshop. Over 20 AWS Heroes & Community Builders have passed through this workshop, plus 1000+ students from the likes of AWS, LEGO, Booking, HBO and Siemens.
  2. If you want to learn how to test serverless applications without all the pain and hassle, you should check out my latest course, Testing Serverless Architectures.
  3. If you’re a manager or founder and want to help your team move faster and build better software, then check out my consulting services.
  4. If you just want to hang out, talk serverless, or ask for help, then you should join my FREE Community.


Leave a Comment

Your email address will not be published. Required fields are marked *