From: Dave Cantrell <ruby-talk@...>
Date: 2006-02-15T14:08:53+09:00
Subject: Re: OO Design Advice

James Britt wrote:
> Jeff Cohen wrote:
>> ...
>> So to render your data for a particular feed, you just instantatiate 
>> the particular renderer that you need for that feed, pass it an 
>> instance of your data, and then let the renderer worry about all of 
>> the formatting.
> 
> But consider what Holub has to say on objects being responsible for 
> rendering themselves.
> ... snip ...
> http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html?

Riposte with Fowler: 
http://www.martinfowler.com/eaaCatalog/dataTransferObject.html

Data Transfer Objects are essentially dumb objects with value accessors, 
and are an integral part of J2EE.

I'm watching a team at work do this (DTOs) as they work with Java on a 
new project (our first one -- we're an Oracle shop). I participated in 
some of the initial design and protested this pattern vigorously because 
it isn't "pure OO".

But it works. Damn well. :)

Plus I recall reading recently (can't recall the source, dammit, but it 
was somebody "important" in the OO world) that fear of creating "too 
many" classes is actually an anti-pattern, as (smartly) creating new 
classes to handle functionality actually makes your code much more 
flexible and easier to maintain and scale.

So yes, I would definitely break the formatting out from the domain code.

Regarding code, I would think approaching it this way would be decent:

order = Order.new(find my order)
formatter = XmlFormatter.new(order)
puts formatter

formatter = HttpPostFormatter.new(order)
puts formatter

Or to use the Strategy pattern:

order = Order.new(find my order again)
order.formatter = XmlFormatter.new
puts order.formatted

...etc...

But I personally like the first one much better, as the domain code 
doesn't have to know ANYTHING about formats, so your design is more 
flexible and adaptable.

-dave

PS I went through a similar discussion today with my DBAs regarding data 
modeling, an area in which I currently have very little experience. I 
was striving for the "pure" approach, or so I thought, which called for 
all kinds of ugliness. I still have to wrap my head around the solution, 
but it similarly breaks out various aspects of the design in ways I 
hadn't thought of before.