OO Design Advice

[eastcoastcoder]

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 Capaldo]

------=_Part_10676_28782683.1139857111900
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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.

------=_Part_10676_28782683.1139857111900--

 

[James Britt]

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

 

[Edward Faulkner]

--9zSXsLTf0vkW971A
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

But consider what Holub has to say on objects being responsible for=20
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. =20

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


--9zSXsLTf0vkW971A
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFD8ODenhUz11p9MSARAgJjAJ983dvVpW7wOfUEmX7Q2u6HZYNaKQCg1u5U
kMykvrASEx/6P5wcOGtcemw=
=zqeh
-----END PGP SIGNATURE-----

--9zSXsLTf0vkW971A--

 

[Francis Hwang]

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 => ostal_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.

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.

 

[Tony Headford]

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

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 Cantrell]

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.