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

Albert Wagner <[e-mail]> writes:

> 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? "

At the same time, there's a big push on the XP front to solve today's
problems today, and solve tomorrow's when and if they roll
around. They call it YAGNI, You Ain't Gonnna Need It, on the basis
that we often overload our code with extra stuff which never actually
gets used.

Think about the addagram. My original solution didn't shown the chain
it used, it just showed the answer. Someone complained, but it turned
out to be easy to add the chain to the code with a minimal speed
penalty. If I remember, David Black then lightly objectified it into a
testing framework. So even non-procedural code can be flexible and
adaptable.

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

I'd say that about 30% of the stuff I do starts out procedurally.
About half of that stays procedural: the rest ends up getting
refactored into explicit objects. It is after all easier to take
procedural code and encapsulate it than it is to take OO code and
flatten it out.


Cheers


Dave