Home | Login | Recent Changes | Search | All Pages | Help

ExtractMethodExample

Example of "extract method" refactorings - pseudocode

"before"

function Verylongmethod

begin

// set up foos

var foos = array [1..3] of foobar

foos[1] = new foobar(2,2,3,4)

foos[2] = new foobar(3,4,6,3)

foos[3] = new foobar(4,67,83,3)

// calculate muckiness

var muckiness = 0

for index = 1 to foos.length

muckiness = foos[ index ] . muckinessQuotient( index ) + muckiness

end for

return muckiness

end function

"after"

function setupfoos

var foos = array [1..3] of foobar

foos[1] = new foobar(2,2,3,4)

foos[2] = new foobar(3,4,6,3)

foos[3] = new foobar(4,67,83,3)

return foos

end function

function calculatemuckiness( foos )

var muckiness = 0

for index = 1 to foos.length

muckiness = foos[ index ] . muckinessQuotient( index ) + muckiness

end for

return muckiness

end function

function Verylongmethod

begin

var foos = setupfoos()

var muckiness = calculatemuckiness( foos )

return muckiness

end function

Now imagine that there is Anotherlongmethod similar to the original function Verylongmethod, where the only difference in how it sets up the foos array. It can be refactored to call the same calculatemuckiness method that had been extracted from Verylongmethod.

"before"

function Anotherlongmethod

begin

// set up foos

var foos = array [1..4] of foobar

foos[1] = new foobar(2,9,3,4)

foos[2] = new foobar(3,9,6,3)

foos[3] = new foobar(4,9,83,3)

foos[4] = new foobar(9,9,9,9)

// calculate muckiness

var muckiness = 0

for index = 1 to foos.length

muckiness = foos[ index ] . muckinessQuotient( index ) + muckiness

end for

return muckiness

end function

"after"

function setupfourfoos

var foos = array [1..4] of foobar

foos[1] = new foobar(2,9,3,4)

foos[2] = new foobar(3,9,6,3)

foos[3] = new foobar(4,9,83,3)

foos[4] = new foobar(9,9,9,9)

return foos

end function

function Anotherlongmethod

begin

var foos = setupfourfoos()

var muckiness = calculatemuckiness( foos )

return muckiness

end function

KeithRay 2003.06.03 Tweaked by BobLee 2003.06.04

Well, I'm confused again. I read this through and went: "Duh." So what's the big news here? Isn't this just obvious, and what any sane person would do? -- JimBullock, 2003.06.05 (Obviously, I'm missing the point.)

I think it's in one of the Change Without Fear patterns.

I also think this is just a case of the tricks of the trade, known only to the practitioners of the highest levels, being just the basics done really well :-)

--DaveLiebreich 2003.06.05

KeithRay 2003.06.05

I admit to a "Duh" repsonse that went unposted. That being said, I totally understand your later point about "Why".

My response to that is "Ack?!, ... NO ... actually it is "Good Question!". I would love to hear what software people have learned, what they would strive for, what they are embarrased by and what might change their assumptions about how SW is built.

Somedays I think the coding techinques of 1970 have been passed down in tact (reliable or comfortable?), and that the newer (lessons learned) techniques have been picked up, sniffed and treated as questionable, pain-in-the-butt accomodations.

BeckyWinant 2003.06.05

If this is what a sane person would do, why do I see so much insane code?

There aren't all that many sane people out there, says me. And I agree with him.

There's tons of it out there, particularly when productivity is judged by LOC.

You answered your own question. Insane situations encourage insane behavior, and may eventually make people structurally insane. Few people have the mental strength to find or maintain sanity in an insane situation. Compare the structure of many work environments or the practices in graduate education with the techniques of cold-war era brainwashing sometime. It's actually surprising we have the frequency of sanity that we do.

SLOC as a measure has it's limits, and it's limited uses. As a measure of "productivity" as in "crank-ye mucho code, oh slave" well, you'll get what you demand and reward. Deming explained why this kind of thing is dumb, talking about widgets. For the products of conceptual work it's doubly dumb.

-- JimBullock, 2003.06.05 (I'd rather let the few geniuses I have known set the standard, and fall short myself, than meet the standard of the common crowd with ease.)

When I started out in Fortran, the units of code were "routines" as in subroutine or function. They were also referred to as "modules" as in modular units of code. When punched card decks were used, module wasn't easily confused with file.

As source code migrated to disk, module came to mean "whatever thingies are stored in a single file". With the C language families, those things I used to call "routines" became "functions" as C had a design bias toward RETURN SOMETHING.

When Object Oriented came along, those thingies that were called functions in procedural language "needed" a different name because "functional" design was deprecated. They became "methods".

This morphing of names to find new, unique terms seems to me to make the field conceptually poorer. True, their intent is to be more precise, but that makes it harder to associate older knowledge patterns that might be applicable. History is harder to match up when the key terms have changed.

Notice how similar it would be of the pattern were named "extract routine" instead of "extract method".

I've noticed similar morphing in terminology in database, and in file systems. Things seem new and complicated until you get that "Duh!" recognition.

--BobLee 2003.06.06 (D-Day + 59 years)

For many people, it seems like their tolerance level for hard-to-read, hard-to-maintain code is high, possibly because their high intelligence lets them sort things out - at least when they're familiar with the code.

I imagine those "tolerant" people get irritated by us "intolerant" Extreme Programmers, who want to the code to be so easy to read that it looks like it was easy to write. There's an old joke in programmers circles - "If it was hard to write, it should be hard to read" - that is unfortunately too true.

Regarding jargon - it's particularly irritating when we invent jargon (like "refactoring") witha precise meaning (RefactoringDefinition) that then gets broadly used as a synonym for "rework".

KeithRay 2003.06.06

DaleEmery 2003.06.06

It's not just you "Extreme Programmers" who are or in this case were intolerant about such stuff. Our vocabulary was not as evolved. We used mostly "crap" and "better" respectively.

As for folks who like that kind of stuff, another way to explain the attraction is to figure they're getting some kind of payoff from the behavior. Me, I'm just too dumb to keep much of this code stuff in my head. The code has to be obvious and clear or I get lost.

-- JimBullock, 2003.06.06