Re: [Htmlparser-developer] factories and prototypes

[Somik R. <so...@ya...>]

Derrick Oswald wrote:
> > And don't get me going about the 'refactoring'
> that spawned the 
> > 'helpers'. All the overhead of creating a new
> CompositeTagScannerHelper 
> > for each node scanned is horrendous -- all to
> avoid a 'large' 
> > CompositeTagScanner class. Sorry, I heartily
> disagree with making 
> > classes smaller in an attempt to avoid a smell,
> when the smell only 
> > shows up when it's 'refactored'.

Just to set the record straight, some of the scanners
were an utter mess. Primarily because I wanted them
stateless- so that one scanner object could be used
throughout the life of a parser. That made refactoring
hard. But moving out functionality into a helper class
allowed the creation of state within the helper on
every parse - that allowed refactoring of large and
obscure methods. 

At certain points, I even threw out the refactored
code and wrote it from scratch. 

I am not sure what you mean by your last statement -
it looks heck of a lot better than when the scanners
had all the code. Sure, there is some penalty for
creating objects every time.. but that happens only
when the scan is essential (triggered off on
identification of a tag). 

I am not in favor of getting rid of the scanner
hierarchy - clients can rig up a parser of their
choice by including a scanner of their choice. Data
files describing scanners could be used to remove some
of the scanner classes.. But it needs to be explored.

I could be wrong - maybe I haven't understood fully
what removal of the scanner hierarchy will buy us..

This is a good debate to have.

Regards,
Somik

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com