OO Design Advice

Ruby
1

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.

2

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.

3

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

4

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

5

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/S39D7.aspx
http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html?
http://www.rubygarden.org/ruby/ruby?WhatIsAnObject

–
James B.

“Blanket statements are over-rated”

6

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.

7

James B. wrote:

http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html?
Riposte with Fowler:
P of EAA: Data Transfer Object

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. :slight_smile:

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.

8

Jeff C. wrote:

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

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