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

[Derrick O. <Der...@ro...>]

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

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.

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.

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.

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

my $0.02

Derrick