Tracking change and innovation in the enterprise software development community
Create REST
-enabled Web Apps
with Project Zero
from IBM.
IBM WebSphere
Virtualize apps
to lower costs,
Increase agility
Learn more!
Terracotta:
Scale your
Apps w/ease
Offload the DB:
Learn More!
QCon San Francisco
Nov 19-21:
+ 80 sessions & tracks
Register now
and Save $400!
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) ?
Scaling a Massively Multi-player Server Casestudy: Terracotta on SmartFoxServer
Hibernate without Database Bottlenecks
Scale Your Application without Punishing Your Database
Why Should I Care About Terracotta?
Terracotta 2.6 - Download now for scalability without tradeoffs
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.
Thin client paradigm characterized by web applications is a kludge that needs to be repudiated. Old compromises are no longer needed and it's time to move the presentation tier to where it belongs.
In this presentation filmed during QCon 2007, Jeff Sutherland, the creator of Scrum, talks about his visit at Google to do an analysis of Google's first implementation of Scrum.
In this article, Bryon Jacob and Chris Berry introduce AtomServer, their implementation of a full-fledged Atom Store based on Apache Abdera, which is now available as open source.
It is easy to think that virtualization applies only to servers. In reality the recent resurgence of the concept is also being applied to networking, storage, and application infrastructure.
In this article, Stefan Tilkov explains some of the most common anti-patterns found in applications that claim to follow a "RESTful" design and suggests ways to avoid them.
In this article, Adrien Louis and Marc Dutoo discuss the differences and relative merits of using orchestration vs. routing in a typical ESB setup, and discuss various implementation options.
Wayne Lund discusses batch processing, Spring Batch objectives and features, scenarios for usage, Spring Batch architecture, scaling, example code, failures and retrying, and the future roadmap.
Developer Jay Fields draws on his experiences as a ThoughtWorks consultant to describe effective user story estimation techniques.
4 comments
Reply