Holding State as Objects is Painful

As a developer, I write code. Code is good. I like code. But the people who use the applications I write could care less about the precious code. They care about.. wait for it... the data. Shocking, isn't it. I could have written the most elegant, wonderful code possible, but if I can't move their SuperApp version 1 files to SuperApp version 2, it's worthless.

Coding usually involves either holding state or executing behavior on the state. Holding state as an object hierarchy is really painful. First, someone has to write all those damn classes that map to the state. Then, changes to the state structure break the object model and any code using the object model. Besides brittleness, object models are a pain to walk (or navigate) and difficult to query or filter. Developers usually have to write other framework objects to support parent/child object relationships. Persisting from an object model can also be a pain and increases the likelihood of problems when the state structure (and therefore object model, and therefore persistence format) changes.

I say it's time to let it go. Focus on the data. Protect it. Ensure it's stored in a way that's robust enough to handle future changes. Think about this: MS Word 97 can open an MS Word 2003 file. Somebody was thinking about the data.

Use code to execute behavior on the data. Separate code from data, just like we're told to separate UI from business logic. If you've been reading my stuff, it should come as no surprise that I favor separating code from data by using XML to hold state. It's a means to an end. XML supports the kind of structure my state needs. It also supports standard ways to quickly walk or query for a piece of data from my state.