Bindings, Platforms, and Innovation
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
News
Designing for flexibility and robustness: Asynchronous message model, OOP and Functional Programming
Posted by Sadek Drobi on Nov 15, 2007 03:00 PM
“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) ?
RelatedVendorContent
5 Ways to Ensure Application Performance
Open Source Middleware Reference Architecture Whitepaper
Same difference
by
Greg M
Posted
Nov 16, 2007 4:37 AM
drunk
by
Steven Devijver
Posted
Nov 16, 2007 7:23 AM
Re: drunk
by
Sadek Drobi
Posted
Nov 16, 2007 7:48 AM
good post
by
jack ding
Posted
Dec 4, 2007 7:30 AM
-
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.
-
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?
-
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.
-
i agree with Feathers. He just threw his thoughts, not solutions.
4 comments
Watch Thread Reply