XmlObject - Adaptive Object Model
Better Designs Faster
Back in my office, my schedule magically cleared of meetings, I was digging through my notes. The rain was coming in sheets. Jennifer was at the window sill watching drops roll down the glass.
“The term is Adaptive Object Model. I know you know what an object model is” I said, “but the adaptive folks, they look at them a little differently. They define object models as belonging to one of two camps. Those that are defined at compile time are called static, and those that are defined at run time are called dynamic.” Adaptive is a further extension of dynamic.”
“With a few small exceptions, Chicago is built on a static object model” I noted.
“What exceptions?” Jennifer asked tracing a drop. “Well, look at how we define cylinders. We define the number of cylinders in an engine, dynamically, at run time.” Jennifer looked towards me.
“With an Adaptive Object Model, everything about an engine would be specified at runtime, not just the cylinders. We call it data driving the object model.”
Jennifer raised her eyebrow, “Everything?” she said. “Yes, pretty much everything.” I replied.
Jennifer frowned. “I don’t see how that is possible.”
“We will supply data that is used to drive object creation.” I responded. “This part is mostly done. We already have an object persistence API that saves application state as XML, correct? Our application uses this API to persist to nonvolatile storage. The developers call it dehydration and rehydration.”
“Yes, it serializes object state as XML. It is kind of complex,” Jennifer said.
“Yes, I know,” I replied. “I want you to think about what happens when we rehydrate, we use a parser to read that XML, and it creates an internal object model. A beautiful object model that is relational and hierarchal. One that is easy to navigate, has built in object creation, and is already storing our data. This parser is expertly written and extensible. It is tested by millions and, best of all, we don’t have to maintain it.”
“So what do we currently do … we use this beautiful object model to create a second object model. One that is much less useful and we throw the beautiful one away.”
Jennifer was frowning, but I could tell I had her attention.
“I’m saying lets get rid of our old inferior object model and just use the good one.
Jennifer’s brow furrowed. “I’m not following you.”
“It is really quite simple. We extend the parser created objects to include our own custom behavior and the parser creates our objects instead of its own” I replied.
“That can’t possibly work” she shot back.
“Yes it can, in fact that part is easy,” I replied smiling. “I have a prototype, parsing your XML.”
“It will be bloated,” she shouted. “Everyone knows that XML is bloated.”
“There are thirteen words of overhead for deriving from System.Xml.XmlElement. Think of all the stuff we don’t have to implement for those thirteen words, object model navigation for instance.”
“What,” she queried? “You know, getting data from one object to use in another. The parser has at least a half dozen ways to do this at runtime. XPath for instance, I can navigate anywhere within the object model with XPath select strings,” I replied.
I could tell that Jennifer was thinking. “So … the XML parser creates our objects for us. These objects will implement our custom methods, but use their own storage. The object model it creates is both hierarchal and relational. It has built in navigation, and is based on an internationally recognized standard. If everything you say is true, it would be a nice improvement over our current design,” she said quietly.
I had to give Jennifer credit. She figured out in 30 seconds what took me hours.
“That is all fine and dandy, but it still doesn’t fix our problem,” she smirked. “All the problems we currently have would still exist.”
“You are absolutely right. In fact if we do just this we have probably made things worse,” I replied. “An Adaptive Object Model is not a silver bullet. It is simply a framework for making the most difficult parts of our job easier.”
“Easier how,” she queried?
“With Adaptive Object Models we will learn to think of objects as data. We will have the ability to manage dependencies as first class aspects of our development.
“What, she blinked.
“You said it earlier, we have inappropriate dependencies. In our current design, if somebody needs some data, they simply go get it. It is all very easy if one doesn’t care about dependencies.” “Ok, it is easy enough to agree with that,” Jennifer replied, “but I’m still not sure what you are proposing.”
“By treating objects as data we create an opportunity to do analysis. We need to understand what is coupled to what and we need to do this much earlier in the development process. With Adaptive Object Models data analysis will become a formal part of our development process.”
“Lets go back to out earlier example. Let’s assume that we have to model a vehicle with a hydrogen fuel cell? Even though it would be a totally foreign concept to our object model I would still guess that most of our business logic would hold up. Some parts won’t though. For example fuel probably won’t be measured in gallons, and miles/gallon will have little meaning” I stated.
“Yes,” she agreed. “We would have to come up with a more basic unit of measure and reimplement everything.” “Yes,” I replied, “and if you reimplement everything, you need to test everything. We simply cannot do that any more.”
“However, by treating our object model as data we can make informed decisions about whether to reimplement, or to create new class hierarchies. I suspect that we would create a new class hierarchy to represent this new engine, but that we would reimplement and test something small, like the fuel gauge logic.”
“That testing problem we had in the last release, we can make it go away. We make it go away by never changing any code that we cannot afford to test and by testing everything we change.”
There is another advantage. By data driving object creation, and not changing existing objects, we can be certain that products already in the field will continue to work. Think how nice that would be.” Jennifer was nodded enthusiastically.
“If we need new an object to work differently we will get that behavior by creating new objects. How many times have you been frustrated by errors and workarounds in our codebase,” I asked? “All the time,” she responded.
“With a data driven object model every release is a chance to start new. It’s every developers dream,” I said with a big smile.
“This is sounding a little too good, what’s the bad news?” Jennifer asked.
“Well, the basic idea is disruptive. Developers are not used to thinking about code as data. Novice developers will have a difficult time. It is much more difficult to understand object relationships.
If anything, there is a greater need for planning. While we can avoid some testing, the testing we do needs to be more comprehensive. We will have some hard decisions to make. Cut and paste reuse becomes seductively attractive.”
Jennifer frowned, “Not on my team!” she exclaimed.
We talked for another hour, but I knew she was warming to the idea. “Jennifer, it’s getting late. Let me point out one more advantage, and you sleep on it, ok?”
Jennifer nodded her head in agreement.
“Consider that all our code will be based on XML. Think of all the things we can do with XML and off the shelf tools … XSL transforms for instance.” Jennifer was an XSLT wizard. “Think of the incredible things we could do by transforming the object model to VML” I said.
Jennifer was again smiling as she left my office. She had noted that our new base class (the one we would derive our classes from) would be yet another way to reduce coupling. It was a good observation. That Jennifer, I need to keep an eye on her.
I was walking out to my car exactly 10 hours after I had arrived. Everything was wet but it had quit raining and there was the barest hint of a rainbow. If I hurried, I still had time to get to a carwash. I rushed towards my car, dodging the occasional puddle. As I approached I was pleasantly surprised to see that the day’s rain had washed it completely clean.