4 Representation is the Essence of Programming
This chapter covers
- The walk through the messy design process
- The effect of AND on our designs
- Modeling options with OR
- Making Illegal states impossible to represent
Rather than a big bang “here’s what data-oriented design is,” we’re going to use this chapter to walk through designing a small feature in all of its chaotic glory. Data oriented design is quite a bit like all design processes: iterative and messy. We’ll make plenty of missteps, hit lots of dead ends, and have to do more than a few total resets. We’ll walk through all those messy bits here because, well, firstly, we’d do them in real life, too (at least when I’m the one doing design). However, beyond that, we walk through all the “wrong” parts so that we can train ourselves to become sensitive to what “wrong” feels like and the symptoms it causes in the code. Once we can put a finger on why something is wrong, making it right is much easier.
What might be kind of surprising is that our design process will be focused entirely on the data in our domain and what it means. Data Oriented design is largely in the spirit of Fred Brooks’ classic observation from Mythical Man Month: “representation is the essence of programming.” If we get the representation of our data right, everything else tends to fall into place. As such, we won’t worry about behaviors, or efficiency, design patterns, or any other operational focused concerns for now.