Michael Feathers recounted a conference run-in with one of the original XP and TDD practitioners:
John Nolan gave his developers a challenge: write OO code with no getters. Whenever possible, tell another object to do something rather than ask. In the process of doing this, they noticed that their code became supple and easy to change. They also noticed that the fake objects that they were writing were highly repetitive, so they came up with the idea of a mocking framework that would allow them to set expectations on objects — mock objects.
That’s a fascinating suggestion, writing OO code with no getters. To think of it in object terms, that means that you create objects that don’t have information extracted from them, they’re only asked to do things. If you take his statement literally and to the extreme, you have the scenario where you don’t know the state of a separate object you can only tell it to do things and hope it does them (you can’t confirm it because there’s no gettable state!). Hmm… that sounds familiar.
I think event-driven programming achieves the goal of “writing OO code with no getters.” It has the added bonus of being dynamically (and anonymously) coupled at runtime. And, in fact, I’ve found event-driven code to be the least brittle. Definitely more complicated in some scenarios (usually trivial cases, while being less complicated for the non-trivial cases), but always more stable, higher quality, fewer bugs.
AS3 has a particularly beautiful event model. When an object dispatches an event the listeners for that event are called immediately (inside of the dispatch function) as opposed to being queued and processed at a later point in time. Callbacks, basically. But at the same time you have to write them as if they occur asynchronously.
I’m not sure the point I’m trying to make… other than to say that event-driven programming is less fragile?