# OO Design Advice

**URL:** <https://www.ruby-forum.com/t/oo-design-advice/67291>\
**Category:** Ruby\
**Created:** [February 13, 2006, 7:33pm UTC](https://www.ruby-forum.com/t/oo-design-advice/67291 "2006-02-13T19:33:37Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\
**Post date:** [February 13, 2006, 7:33pm UTC](https://www.ruby-forum.com/t/oo-design-advice/67291/1 "2006-02-13T19:33:37Z")

</div>

I’m trying to master the more subtle elements of Rubyish OO design, and  
am having trouble with the following aspect:

I have a complicated, nested, value object ( eg  
order.customer.address.zipcode, or order.product[0].description).

This object needs to be sent to various feeds (usually XML, sometimes  
REST / HTTP form ) run by other companies. Each company has a slightly  
different format in which they want some of the items (eg, some might  
want CA and some California, some might want the description to use one  
set of abbreviations and some another).

Now, the feeds are added fairly frequently, and so a goal of the design  
is to allow new feeds to be created without having to modify the core  
code.

Questions:

1. Which object should be responsible for formatting a field according  
to one spec’s choice? Should it be  
product.format\_description\_for(feedX), or  
feedX.format\_description(product) ? “Tell, don’t ask” would indicate  
the first. The product knows better than anyone how to describe  
itself. But there are two arguments for the latter: A) New feeds can  
be added without touching the product code and B) Feeds know which type  
of formats they need - very often, different feeds could use the same  
formats for many fields.

It seems that the root of the problem is that OO design tells us to put  
logic with the data it operates on, and to push decisions out to that  
thing. But here, the question can be answered only by two things  
working together: the order (which knows about itself) and the feed  
(which knows what type of formatting it needs).

Ideas?

1. What type of method call should I use to format the fields? It can  
get cumbersome to always add a formatter, even when it’s not needed (eg  
I’d rather just pass order.customer.address.zipcode, and have the to\_s  
called implicitly, than have to always write  
order.customer.address.zipcode.format\_for(feedX) - when zipcodes are  
almost always formatted the same). The code could be made more succint  
by just adding an instance variable @formatter, and having to\_s  
automatically use that. But there are two problems with that A) How  
would subobjects find the @formatter? In other words, we can set  
order.formatter, but how will order.customer.address find the  
formatter? and B) This violates encapsulation - if, in the middle, we  
need a field in a different format, we can mess things up without  
realizing.

So: Is there a good solution to avoid having the repetition of  
constantly appending .format\_for(feedX)?

All ideas/comments/criticisms/creativity appreciated

PS Yes, I know that a nested value object arguably violates demeter.  
PPS If it’s relevant, the XML is generated using ERB templates.

---

<div class="post-metadata">

**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\
**Post date:** [February 13, 2006, 7:59pm UTC](https://www.ruby-forum.com/t/oo-design-advice/67291/2 "2006-02-13T19:59:00Z")

</div>

Here’s one idea, pick a very verbose canonical format. Then teach all  
your  
objects how to convert to that. Then teach the cannonical format hwo to  
convert itself into any of the other feed formats you might need. This  
way  
you still only add the new feed type in one place, and the object knows  
how  
to format itself.

---

<div class="post-metadata">

**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\
**Post date:** [February 13, 2006, 8:10pm UTC](https://www.ruby-forum.com/t/oo-design-advice/67291/3 "2006-02-13T20:10:47Z")

</div>

unknown wrote:

> I’m trying to master the more subtle elements of Rubyish OO design, and  
> am having trouble with the following aspect:
> 
> I have a complicated, nested, value object ( eg  
> order.customer.address.zipcode, or order.product[0].description).
> 
> This object needs to be sent to various feeds (usually XML, sometimes  
> REST / HTTP form ) run by other companies.

I say, you should definitely abstract away the “rendering” of the data  
from the data model itself. I would recommend reading up a bit on the  
“strategy” design pattern, but basically the idea is to take something  
that varies (i.e. your feed formatting) and separate it from the things  
that don’t vary (your data model).

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.

Make sense? I can elaborate more if that would be helpful.

Jeff

> **[Hey Daddio!](http://www.softiesonrails.com)**
>
> Home of Hey Daddio Software

---

<div class="post-metadata">

**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\
**Post date:** [February 13, 2006, 8:42pm UTC](https://www.ruby-forum.com/t/oo-design-advice/67291/4 "2006-02-13T20:42:56Z")

</div>

On Tue, Feb 14, 2006 at 04:32:18AM +0900, James B. wrote:

> But consider what Holub has to say on objects being responsible for  
> rendering themselves.

That works great when there’s only one kind (or a few kinds) of  
rendering. But it doesn’t scale well with the number of output  
formats, which is what’s needed in this case.

If you have n classes and m ways to render them, you’ll write n\*m  
methods.

Instead, you can write a single canonical output method in each class  
and then implement renderers separately. This gives you n+m methods.  
Much more scalable.

regards,  
Ed

---

<div class="post-metadata">

**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\
**Post date:** [February 13, 2006, 8:32pm UTC](https://www.ruby-forum.com/t/oo-design-advice/67291/5 "2006-02-13T20:32:29Z")

</div>

Jeff C. 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.

[http://www.microsoft.com/msj/archive/S3F6.aspx](http://www.microsoft.com/msj/archive/S3F6.aspx)  
[http://www.microsoft.com/msj/archive/S39D7.aspx](http://www.microsoft.com/msj/archive/S39D7.aspx)  
[http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html](http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html)?  
[http://www.rubygarden.org/ruby/ruby?WhatIsAnObject](http://www.rubygarden.org/ruby/ruby?WhatIsAnObject)

–  
James B.

“Blanket statements are over-rated”

---

<div class="post-metadata">

**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\
**Post date:** [February 13, 2006, 9:08pm UTC](https://www.ruby-forum.com/t/oo-design-advice/67291/6 "2006-02-13T21:08:39Z")

</div>

Personally, I’d be skeptical of the value of an intermediate canonical  
form, though I suppose this might depend on how different the feeds are  
from one another. But generally, I think Ruby offers lots of  
opportunities for factoring into common utility code, enough that an  
intermediate format is arguably less useful in Ruby than in a more  
verbose language.

If I were in your shoes, I think I’d make separate feed classes, backed  
by lots of tests, and then look aggressively for opportunities to  
refactor into common methods. In Ruby, factoring can take lots of  
inventive forms, such as custom iterators like #each\_product. And don’t  
forget there’s lots of chances for reflectivity. For example:

class AbstractFeed  
def format\_state  
state.send “to\_#{ state\_format }”  
end  
end

class FeedA \< AbstractFeed  
def state\_format; “fullname”; end  
end

class FeedB \< AbstractFeed  
def state\_format; “postal\_code”; end  
end

Maybe you could even define yourself a mini-feed DSL, so that classes  
could look like:

class FeedA \< AbstractFeed  
formats :state =\> :fullname, :zipcode =\> :five\_digits  
end

class FeedB \< AbstractFeed  
formats :state =\> :postal\_code, :zipcode =\> :nine\_digits  
customers\_select { |c| c.orders.size \>= 1 }  
orders\_select { |o| o.amount \>= 100.0 }  
end

… though this may also be more or less useful depending on how widely  
the feeds vary.

---

<div class="post-metadata">

**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\
**Post date:** [February 15, 2006, 6:11am UTC](https://www.ruby-forum.com/t/oo-design-advice/67291/7 "2006-02-15T06:11:53Z")

</div>

James B. wrote:

> [http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html](http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html)?  
> Riposte with Fowler:  
> [P of EAA: Data Transfer Object](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.

---

<div class="post-metadata">

**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\
**Post date:** [February 13, 2006, 10:34pm UTC](https://www.ruby-forum.com/t/oo-design-advice/67291/8 "2006-02-13T22:34:52Z")

</div>

Jeff C. wrote:

> Make sense? I can elaborate more if that would be helpful.
> 
> Jeff  
> [www.softiesonrails.com](http://www.softiesonrails.com)

In my experience what Jeff suggests is the right OO way to go. The  
model does not need to know how to render itself for specific feeds,  
that would be a function of the feeds themselves or an adapter class.

cheers,  
Tone.