Re: OOP overhead (Was: tiny contest...)

On Sunday 17 February 2002 09:00 pm, you wrote:
<snip>
> However, I don't think this is an indictment of OO either. When you
> design OO structures, you have to make the same tradeoffs that you
> make with procedural ones in order to get performance. Sometimes this
> means breaking encapsulation in order to cache data, or break long
> method chains. The trick then is to encapsulate the damage (in the
> example above, this might involve making the wordlist an class which
> hides the hashing business from the outside world). I suspect I could
> re-structure the addagram solution this way with no more than a 10-15%
> penalty.
>
> However, that then raises the interesting question.
>
> Why?
>
> In this case, is there a benefit to an OO solution? 
<snip>
> Dave

I suppose this is closer to the question I was trying to ask.  My first 
solutions were to problems that weren't put forward.  Only after looking at 
your code did I realize how fine the laser beam was.  They didn't ask for a 
list of the longest chains or a list of the longest words.  Plus, it's 
basically a "throw-away" solution, having no utility beyond the finding a 
single answer in a single list.  In my actual work I don't believe I have 
ever encountered such a request from a user who didn't come back the next day 
and say something like "Can you also get me a list of all chains between  6 
and 28 that include no 'a's? "

So, I am of the current opinion that there are indeed some problems that do 
not benefit from an OO solution.  However, I would be interested in hearing 
some heuristics for spotting these problems up front.





-- 
Quantum Mechanics: The dreams stuff is made of