Designing for flexibility and robustness: Asynchronous message model, OOP and Functional Programming

Posted by Sadek Drobi on Nov 15, 2007

Sections

Architecture & Design,

Development,

Enterprise Architecture

Topics

Messaging ,

Modeling ,

Design ,

Performance & Scalability ,

Object Oriented Design ,

Architecture

Tags

Erlang ,

Functional Programming ,

OOP ,

Haskell ,

Parallel Programming

“Tell, Don't Ask”: according to Pragmatic Programmers it is preferable in object oriented programming to “tell an object to do something rather than asking it for some data.” Michael Feathers believes that “this is a great piece of advice”, especially for larger systems:

Return values push work back on callers. It's not enough to do some work and decide to send a message to a collaborator; you have [to] wait for something to come back to you and then, perhaps, do some more work. We're better off not returning values.

According to Feathers, using mocks in test driven development results in this kind of architecture:

Rather then telling an object to do something and then asking whether it was done, you tell an object to do something and then see what happens to its collaborators. […]They are a bit like a workflow. […] There's less design impact under new requirements. And, it makes sense. Each object is responsible for doing one thing and notifying its successor.

One can go beyond this. Feathers argues that if there is no return value to wait for, it may be better to send “asynchronous messages send rather than synchronous messages”. H.S. Lahman has actually been arguing that in object oriented architecture “behavior is assumed to be asynchronous”. Today’s OOP model, however, is synchronous because in object oriented programming languages “message and method are not separated”. This makes it “more difficult to construct correct OOA/D models” that could significantly improve not only maintainability but also robustness.

This maps to the Erlang model as described by Michael Feathers:

The idea behind Erlang is that if you can make a large number of processes and guarantee that they never share state, you can develop more robust systems. Each process receives messages, does its work, and sends messages to other processes. The message sends are largely asynchronous.

According to Feathers, the “Tell, Don’t Ask” model of programming is “almost the opposite of functional programming” even though “both of them seem to have a relatively stateless substrate that data flows along”:

In the purest form of functional programming, you never tell; you ask. And when you have lazy evaluation, the system only does as much as it really needs to when it's answering your question.

Arguably, Erlang cannot be considered a purely functional language, as highlighted by Feathers referring to Ralph Johnson who has pointed out that Erlang is “OO in its core”.

In your opinion, which stateless model is the best for handling today’s adaptability and robustness issues: Erlang’s asynchronous message model or a pure functional programming approach (e.g. Haskell) ?

1. Back to top

   Same difference

   by Greg M

   Depends where you want explicit parallelism. Haskell uses tell-don't-ask message queues for explicit parallelism, Erlang uses purely functional or-near-offer code within processes. It's just that Erlang is more targeted at explicitly parallel applications, hence has excellent library and runtime support.

   Reply

2. Back to top

   drunk

   by Steven Devijver

   This discussion suffers from a terminology hangover.
   
   What is meant with responsible, successor, workflow, notifying, collaborators, ... ?
   
   What's the expected extend of improvements in maintenance, robustness, implementing new requirements?
   
   It's so so fuzzy. How do you expect this to be useful in any way?

   Reply

3. Back to top

   Re: drunk

   by Sadek Drobi

   The discussion unfortunately doesn't offer any checklist. And it wasn’t the intent anyway. What interesting about it is the reflection it triggers... For me at least thinking is much more important than checklists, especially viewing things from different angles.

   Reply

4. Back to top

   good post

   by ding jack

   i agree with Feathers. He just threw his thoughts, not solutions.

   Reply

• Older >