Render yourself ou ask someone else to render you?

Hi,

Here is a quick OO design question. Suppose I have a few objects that I
would want rendered in HTML (Article, Category). What would be the best
OO way to render them? (BTW, the language is PHP)

If I am not mistaken,

1) the Strategy pattern would instruct me to pass the rendering to
another object. So I would have HTMLArticleRenderer that is constructed
using an Article object and that will render using
HTMLArticleRenderer->render(). If I wanted to add a PDF output, I could
just add a PDFArticleRenderer and switch renderer at runtime.

2) the Decorator pattern would instruct me to add a render() method to
every object (Article, Category) so they could be called in a tree-like
fashion.

I want your opinion on which would be the best solution or the
cleanest?

Regards,

Vincent

<vincent.bouret@gmail.com> wrote in message
news:1134538032.486439.26380@f14g2000cwb.googlegroups.com...
> Hi,
>
> Here is a quick OO design question. Suppose I have a few objects that I
> would want rendered in HTML (Article, Category). What would be the best
> OO way to render them? (BTW, the language is PHP)
>
> If I am not mistaken,
>
> 1) the Strategy pattern would instruct me to pass the rendering to
> another object. So I would have HTMLArticleRenderer that is constructed
> using an Article object and that will render using
> HTMLArticleRenderer->render(). If I wanted to add a PDF output, I could
> just add a PDFArticleRenderer and switch renderer at runtime.
>
> 2) the Decorator pattern would instruct me to add a render() method to
> every object (Article, Category) so they could be called in a tree-like
> fashion.
>
> I want your opinion on which would be the best solution or the
> cleanest?

I believe web applications are generally written using the Model View
Controller pattern. It sounds like "Article" is your model, and so you need
to create a View; e.g. "HTMLView" or "PDFView" which can receive an article
and generate and HTML or PDF representation of it.

That's closer to your (1) than your (2), I think.

- Oliver

I would use a strategy for this based on what you have stated.
Based on the limited detail you gave a and about 3 mins to think about
it I would do something like this.

1.Create a abstract class or an interface called IRenderable.
2.Implement the base level impl or create the public interface that all
things that need to have to be rendered.
3.Implement your concrete classes that either inherit from this base or
implement the interface. (I.E. Strategy)
4.Create a class to render anything the implements or inherits
IRenderable.

This can still be done using a Model View Controller and in fact it can
help you in writing less view code if your your Model is a IRenderable
object or a IRenderable collection all you would need is one View page
to render anything that is IRenderable.


Just my 4 cents.

PitDog

Oliver Wong wrote:
> <vincent.bouret@gmail.com> wrote in message
> news:1134538032.486439.26380@f14g2000cwb.googlegroups.com...
> > Hi,
> >
> > Here is a quick OO design question. Suppose I have a few objects that I
> > would want rendered in HTML (Article, Category). What would be the best
> > OO way to render them? (BTW, the language is PHP)
> >
> > If I am not mistaken,
> >
> > 1) the Strategy pattern would instruct me to pass the rendering to
> > another object. So I would have HTMLArticleRenderer that is constructed
> > using an Article object and that will render using
> > HTMLArticleRenderer->render(). If I wanted to add a PDF output, I could
> > just add a PDFArticleRenderer and switch renderer at runtime.
> >
> > 2) the Decorator pattern would instruct me to add a render() method to
> > every object (Article, Category) so they could be called in a tree-like
> > fashion.
> >
> > I want your opinion on which would be the best solution or the
> > cleanest?
>
> I believe web applications are generally written using the Model View
> Controller pattern. It sounds like "Article" is your model, and so you need
> to create a View; e.g. "HTMLView" or "PDFView" which can receive an article
> and generate and HTML or PDF representation of it.
>
> That's closer to your (1) than your (2), I think.
>
> - Oliver