Re: [Htmlparser-developer] toPlainTextString() feedback requested

[Joshua K. <jo...@in...>]

> IMHO the visitor pattern is not a good one. Here are the reasons.

The Visitor pattern is a fine pattern Derrick.  Ralph Johnson once said,
"Most of the time you don't need a Visitor, but when you need a Visitor, you
really need a Visitor."

> It breaks encapsulation.  It presumes that an exterior class (the
> visitor) knows how to do something to a class better than the class
> itself does.

A good many of the Design Patterns "break encapsulation."   I guess those
aren't good patterns, huh?   Is there an OO police agency to report
instances of breaking encapsulation?   ;-)

> It makes the system brittle.  The visitor class has a method defined for
> every subclass of visited object.  Adding, removing or refactoring any
> visited class breaks the visitors.

Hard-coded, duplicated logic in nodes makes class hierarchies brittle.

We've found that the html parser code doesn't need special visit methods for
each tag type, which means it's easy to implement Visitor and it won't be
hard to accomodate visiting new tags in the future.

BTW, do you envision needing to add many new tag types to the html parser?

> It's obscure.  Looking at the visit loop tells you nothing of what is
> being perfomed.  The only indication of the task might be the name of
> the visitor class.

If you call a method that yields the plain text string for some html, and
that code happens to use a Visitor, do you care?   That is, a client won't
even know they're using the pattern.

> It's redundant.  In every example I've seen (I've never seen it used in
> real applications), the result could have been coded in a simpler
> fashion with correct class design.

I agree that it's always best to seek out the simple design.  It takes a
committment to refactoring to find simplicity.  Presently, Somik and I are
removing duplication to get to a simpler design.  You have our promise that
no Visitor will be added if it complicates the design.

> I would only use the visitor pattern if either the set of public methods
> on the visited nodes completely specify their possible behavior and
> allowed the client to fully manipulate them at the highest level of
> abstraction (i.e. everything you can do to the visited classes is
> already coded and you don't want them to change), or the visitor pattern
> had already been coded into the visited nodes and for some reason they
> could not be modified further (i.e. the code was available in binary
> form only).  I don't think either of these applies here.

Visitor is a great pattern when you need various operations to be performed
over an object structure and you don't want to hard-code those operations
into the objects themselves.  So far, it seems to me you have just that need
in html parser.  I could be wrong.  We'll have to see how the code feels
with a Visitor implementation and make decisions based on real code.  CVS
allows us to go back to any previous implementation we like better.

best regards,
jk