|
|
Posted by rf on 08/25/07 08:23
"Sanders Kaufman" <bucky@kaufman.net> wrote in message
news:whNzi.24$FO2.2@newssvr14.news.prodigy.net...
> Jerry Stuckle wrote:
>
>> No, refactoring is changing the implementation without changing the
>> interface.
>>
>> IOW, you change HOW you do things, but not WHAT you do. You changed the
>> interface.
>>
>> An example of refactoring would be to change a class so that it gets its
>> data from a relational database instead of a flat file. The function
>> calls (interface) remain the same, but the code in the functions
>> (implementation) changes.
>>
>> Refactoring in OO would mean you would not have to change anything
>> outside of the class itself.
>
> Ahh - so when I had to use new kinds of parameters - I was rewriting. But
> if I'd made it all zero-impact on how it's used, it would have been
> refactoring.
>
> I don't get it. I can repeat it and rephrase it. But I don't get it.
This is a real example, taken from the 1970's but still valid.
A function was required to invert a matrix. The programmer decided to use
one method [1] which worked perfectly on the 6x6 test matrix. However when a
real world matrix was fed to the function took too long (estimates (by IBM)
were that for a 30x30 matrix it would have taken, with the then current
hardware, thousands of years to complete).
The function was refactored to use a different [2] method, which inverted
the 30x20 matrix in seconds.
This was _not_ fixing a bug, or even a programming mistake. It was changing
internals of the function to use a more efficient algorithm. Nothing in the
functions interface changed.
[1]
Using determinates, as discussed here
http://mathworld.wolfram.com/MatrixInverse.html
The method is of course recursive. The order of the algorithm is, I forget,
but very high, N to power of N or something.
[2]
Using reduction like done with systems of linear equations, discussed here:
http://www.purplemath.com/modules/mtrxinvr.htm
Order is about N IIRC.
--
Richard.
Navigation:
[Reply to this message]
|