Recently I met a developer who deeply knows his problem domain. Yet when his colleagues split hairs arguing about the behaviors of concrete and abstract classes, whether to craft an interface, or even how to give them meaningful names he’s confounded. He’s a smart guy. But the nuances that object geeks just love to roll around in drive him nuts. Where’s the hard and fast, proven concrete advice for using these techniques? Enough debate and theory already!
This reminds me of another developer who sent me a lengthy email a couple of years ago, asking whether I could shed light on how to decompose problems using “behaviors” instead of functional decomposition. He copied other lengthy emails from other experts and authors—I wasn’t the first he’d asked.
I was quite impressed by how thoughtful those experts’ responses were. But they didn’t help him learn how to do behavioral decomposition. Instead of seeking out nuanced differences between object responsibilities, actions, and behaviors and what made a design object-oriented or not, he should have been studying examples of different ways to decompose the same problem. Compare, contrast, then reflect. Seeking definitions and nuanced meanings was barking up the wrong tree! At the time, I wasn’t sure I wanted to be yet another in that long chain. So I didn’t answer his email.
But these two responses by smart people got me thinking. Nuanced discussions can be infuriating if you haven’t internalized any rules of thumb about when and why to do something. If you are the person in that spot, don’t let those discussions choke your curiosity or drive you crazy. Instead, I advise you to live a while with uncertainty about the distinctions between shaded meanings or the relative strengths and weaknesses of one technique over another. Don’t try to disambiguate by thinking about what others say. Instead if you can, experiment with different solutions to meaningful problems that you have, perhaps with the help of a thoughtful colleague or guide. Then reflect on what you thought was important. Let the nuances come to you after you’ve personally wrestled with distinctions and techniques for a while. And don’t expect experts or colleagues to share the same values, use words the same way, or make the same judgment calls (when this happens the world as we know it will end).
As to what behavior means in an object-oriented context? The short answer is: the same as it does in any other. But how people use language is incredibly sloppy. Behavior is defined as “how someone behaves”(how’s that for a circular definition in the American Heritage Dictionary?) or, more usefully, “the actions or reactions of a person or animal in response to external or internal stimuli.”Replace person or animal with software object and that definition seems to fit pretty well. But behavior also means “the manner in which something functions or operates” a more general characterization of how something functions in a particular context. So we can talk about behavior of a dying star, a frightened mouse, or even software objects.