Controversial Topic: Object Graphs

Controversial Topic: Object Graphs

Old forum URL:

jh72i posted on Friday, August 26, 2011

I don’t I don’t necessarily want to go over old ground (nor open up old wounds Smile). I just want to open a discussion by asking a question that has been asked and answered many times but ask it in a different way.

I like object graphs. I like to encapsulate behaviour into objects and I even like to have them manipulate their own data. I like to model my world in use cases too. But I don’t like to limit my view of the world for a specific application. Ok, I’m happy enough to do that when I’m in and out – tasked with solving a specific business problem and thanked (as if!!) and on my way to the next job. But if I stay about I generally find the same domain items crop up again and again.

Ok, I know there are some contradictions even in that short paragraph but I want to focus on one specific thing here that I believe is important regardless of your leanings and that is the use of object graphs.

I have a theory that us developers are fooling ourselves into believing object graphs are bad design and, by proxy, breaking the tenets of OO encapsulation because……….of our UIs!

Because databinding and vendor controls have never happily supported deep graph binding (2way) doing anything with a UI to achieve this type of thing involves the pain of mappers, presentation objects delegating here and there, etc.

I will admit here and now that I absolutely hate to write an object that simply delegates to the real thing. It’s fundamentally wrong in my head. Its nails scraping on the black board (another redundant technology these days of course!) to my sensibilities. Its (at least) double the code, double the possibility of getting out of whack, double the pain in explaining why a code change isn’t just in one place which is/was a big selling point of OO to management at least. And, of course, what you might find yourself ending up doing is:

  1. Adding every possible property to the presentation object to avoid that case where the business want to see some other attribute/property on screen and you have to tell them its coding, testing, release cycle, etc. and they’ll have that in 3 months!
  2. Pushing properties upward in the hierarchy inappropriately to business objects where they really don’t belong. 
  3. Deciding that in this particular, specific use case all those properties and underlying behaviours are required and therefore an object graph is unnecessary and the single object is the perfect solution.

Years ago I had the very situation in a product suite I developed for a company who sold it as much as they could (why don’t developers get royalties!). Thing was that each company who bought it placed different emphasis on what properties were of most important to their business model. But the business domain was the same regardless of their view of their world. Obviously we couldn’t tailor different solutions for different businesses or we’d be dead in the water. So I wrote something I think I called the SmartDataView or SmartDataViewer. This sat between the business layer and the UI and basically did the job that databinding couldn’t in terms of 2-way binding to deep object properties. This allowed us to ply the same object model yet choose on-site what properties of the complete graph were displayed to the users.

Ok, that last anecdote isn’t totally relevant to the theory I wanted to present to you so if this topic does interest you please don’t focus on that.

I’d love to hear the thoughts of you folk who are out there building real applications with complex business layers and presentations: If databinding always allowed you, from the dawn of time, to 2-way bind in a car.engine.crankshaft.position manner would you think differently about object graphs.

Copyright (c) Marimer LLC