« Refactoring is Sloppy | Main | The Framework Superclass Anti-Pattern »

January 22, 2013

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d8341d798c53ef017c362175d0970b

Listed below are links to weblogs that reference The Parnas Extraction:

Comments

Andrew Johnson

In your first refactor I would have called the method getEmailAddressFromFile. In your second I don't know what I would have called it, but it would have called getEmailAddressFromFile. What is this global/default list of email addresses? What's its purpose? Can we name it?

When refactoring I think less about hiding implementation details and more about programming to a consistent level of abstraction, and making the method body easy to understand. Method name should embody what it does and method body is how it does it. I think you raise a good point about considering at what level of abstraction each design decision belongs, but doesn't that often fall out of aiming for "The method does and it does it by "?

Ben

Glad to have a name for it - is it synonymous with composed method?

When I do this I feel like am coalescing a new object while separating an object's intent from implementation. Which means both are clarified. I like to use it when approaching a refactor in unfamiliar territory.

J. B. Rainsberger

The "long way" simply involves extracting a few tiny things, seeing duplication in the names, then combining them into what you have here. :)

The comments to this entry are closed.