Steve Freeman

Michael Feathers has kindly cited Nat Pryce and me in his recent discussion about how asynchronous messages should be. He talks about the approach to coding that we like to take, which informed our approach to jMock. I love Ralph Johnson’s description of this as the “mystical view” of O-O.

I think both of us were influenced by functional languages. These days, I find a high proportion of my methods seem to consist of chained calls to other methods, with not many variables and a lot of closing parentheses—probably to excess.

What we tend to find is that we end up sort-of passing behaviour to the data, so it’s almost the opposite of the shell pipeline. This draws on the other neat part of functional programming, throwing around partially bound functions. The pattern looks a little like this: when an event happens, figure out who wants to know and create an object to represent them; then pass that object around the runtime until you find something that can feed it the data it needs. As Michael says, the substrate is relatively stateless which means we localise the coordination issues in just a few places.

The original mockobjects idea came from an experiment at Connextra where they asked the question, “what if we wrote objects without any getters?” My only addition is that you have to do it for a while before the effects start to kick in, anything will work in a small enough example. It’s obviously too extreme, but try it for a while.