Forum: Ruby OO Design Advice

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
unknown (Guest)
on 2006-02-13 20:33
(Received via mailing list)
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?

2. 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.
Logan C. (Guest)
on 2006-02-13 20:59
(Received via mailing list)
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.
Jeff C. (Guest)
on 2006-02-13 21:10
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
www.softiesonrails.com
James B. (Guest)
on 2006-02-13 21:32
(Received via mailing list)
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-0...?
http://www.rubygarden.org/ruby/ruby?WhatIsAnObject


--
James B.

"Blanket statements are over-rated"
Edward F. (Guest)
on 2006-02-13 21:42
(Received via mailing list)
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
Francis H. (Guest)
on 2006-02-13 22:08
(Received via mailing list)
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.
Tony H. (Guest)
on 2006-02-13 23:34
(Received via mailing list)
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.
Dave C. (Guest)
on 2006-02-15 07:11
(Received via mailing list)
James B. wrote:
> http://www.javaworld.com/javaworld/jw-09-2003/jw-0...?
Riposte with Fowler:
http://www.martinfowler.com/eaaCatalog/dataTransfe...

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.
This topic is locked and can not be replied to.