Exercises in Programming Style–Letterbox

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 ;-)

 

Constraints

• 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.