« ROME article | Main | Architecture Diagram »

Edge Case

Martin Fowler:

"Another good warning sign of trouble is the Data Class - a class that has only fields and accessors. That's almost always a sign of trouble because it's devoid of behavior."

This is good OO design advice inside the application boundary, for local cases. But when it comes to working at the application edges - at the network boundary, over HTTP, between applications, intra-app messaging - well, "I have a doubt." For example Data Classes are a really really good thing, if they happen to be Atom served over HTTP or across an MQ. The advice about Data Classes is not actually wrong tho', it's just highly context sensitive. It's suprising that Martin Fowler doesn't qualify his advice as pointing out edge cases is something I've come to expect in his writing.

Anyway. There's a lot of system edges these days, and agreeing where the edges are is hard. Arguing that data classes are bad design is the kind of advice that can result problems when working with HTTP or SOAP, or as Steve Loughran out it, "The doomed attempt to seamlessly map from local structures and method calls into XML documents". Object-centricity and one-size-fits-all approaches to modelling is the sort of thing that stops me really liking books like Domain Driven Design, which is also down on Data Classes as well as Service Layers.

update: Tony Coates goes into a bit more detail on this.


February 27, 2006 12:28 PM

Comments

Pete Kirkham
(February 28, 2006 10:30 AM #)

Isn't this all just an argument for better mapping tools for serialized formats to domain objects - many of the mapping tools only generate data class code and can't inject it into domain objects, many of the development environments don't have automatic mechanisms for hiding injected code. Because the tools don't hide the data mapping when working from the domain viewpoint, that forces the extra data object intermediate to exist as a the access point for the data, rather than making serialization a transparent feature of the environment the domain objects reside in.

Rob Lally
(February 28, 2006 12:53 PM #)

Hi Bill,

You describe Data Classes used in edge cases as "a really really good thing", and I have to disagree. I'm not saying you shouldn't have them, they are a 'really really neccesary thing' but it would be better if you didn't have to have them.

Data Classes/DTOs are a work-around for the problems that these edge cases present; they are not a desirable goal in of themselves. This is something that I think a lot of developers have either lost sight of or never understood in the first place. I blame the misuse of J2EE Patterns for this, people have looked at the patterns solutions without looking at the contributing forces and assumed that these patterns were goals to be achieved rather than techniques to help your design in specific circumstances.

Reminds me 10 years agoand the way all of the problems of global variables were solved by making them into Singletons.

Post a comment

(you may use HTML tags for style)




Remember Me?

Trackback Pings

TrackBack URL for this entry:
http://www.dehora.net/mt/mt-tb.cgi/1754