TITLE: Primitive Obsession and Balance AUTHOR: Eugene Wallingford DATE: May 31, 2005 4:58 PM DESC: Primitive Obsession is a smell, for sure. But let's not go too far... ----- BODY: Recently, Chris Wheeler posted a thoughtful blog entry called My Favourite Smells, which described only one smell, but one every OOP programmer knows deep in his soul: using a primitive data type instead of a domain-specific type. James Shore calls this smell Primitive Obsession, and Kevin Rutherford calls it Primitive Feature Envy. Chris has been justifiably lauded for starting a conversation on this topic. I find this smell in my programs and even in many of the programs I read from good OOP programmers. When programmers are first learning to write object-oriented programs, the tendency to write code in terms only of the primitive data types is hard to shake. Who needs that Piece class, when a simple integer flag taking values from 1 to 4 will do just fine? (Heck, we can always use Hungarian Notation to make the semantics clear. :-) When students come to see the value of that Piece class, they begin to see the value of OOP. That said, we have to be careful to remember that this smell is not an absolute indicator. There is an inherent tension between the desire to create classes to model the domain more closely and the desire to do the simplest thing that could possibly work. If I try to wrap every piece of primitive data in its own class, I can very quickly create a lot of unnecessary code that makes my program worse, not better. My program looks like it has levels of abstraction that simply aren't there. That's not the sort of thing that Chris, James, and Kevin are advocating, of course. But we need to learn how to strike the proper balance between Primitive Obsession and Class Obsession, to find the abstractions that make up our domain and implement them as such. I think that this is one of the reasons that Eric Evans' book Domain-Driven Design is so important: it goes a long way toward teaching us how to make these choices. Ultimately, though, you can only grok this idea through experience, which usually means doing it wrong many times in both directions so that your mind learns the patterns of good designs. As Chris', James', and Kevin's articles all point out, most of us start with a predilection to err on the side of primitives. One way to push yourself to learn this balance is to use the Three Bears pattern first described by Kent Beck to create situations in which you confront the consequences of going too far one way or the other. I think that this can be another one of those programming etudes that help you become a better programmer, a lá the Polymorphism Challenge that Joe Bergin and I used at SIGCSE 2005, in which we had folks rewrite some standard programs using few or zero if statements. In order to feel the kind of effects that Chris describes in his article, you have to live with your code for a while, until the specification changes and you need that tolerance around your masses. I think that the folks running the ICFP 2005 programming contest are using a wonderful mechanism to gauge a program's ability to respond to change. They plan to collect the contestants' submissions and then, a couple of weeks later, introduce a change in the spec and require the contestants to adapt their programs on an even shorter deadline. What a wonderful idea! This might be a nice way to help students learn the value of adaptable code. Certainly, Primitive Obsession is not much of a problem if you never encounter the need for an abstraction. Ron Jeffries posted a message to the XP discussion list earlier today confessing that one of his weaknesses as a programmer is a tendency to create small classes too quickly. As an old Smalltalker, he may be on the opposite end of the continuum from most folks. But we need a good name for the smell that permeates his code, too. My "Class Obsession" from above is rather pedestrian. Do you have better name? Please share... Whatever the name, I suspect that Ron's recognition of his tendency makes it easier for him to combat. At least he knows to pay attention. Chris's article starts with the idea of favorite smells but then settles on one. It occurs to me that I should tell you my personal favorite smell. I suspect that it relates to duplication; my students certainly hear that mantra from me all the time. I will have to think a bit... -----