Refactoring private methods is like...?

re: Refactoring private methods is like...?

Colin Jack — Mon, 21 Jan 2008 13:14:41 GMT

Didn't read all the comments but I agree with Casey Barton in that its about the visibility rather than the size of the change and so the analogy doesn't work for me.

re: Refactoring private methods is like...?

flipdoubt — Sun, 20 Jan 2008 13:37:09 GMT

Refactoring private methods is like repairing or replacing old, faulty plumbing with new stuff. Refactoring public methods is like getting a new sink and faucet.

re: Refactoring private methods is like...?

dotan — Wed, 16 Jan 2008 09:57:59 GMT

changing a private method is like dealing with YOUR privates: wearing boxers instead of tanga. it makes you feel better (to some) and people can tell only by the look on your face :).

changing a public method is wearing a different coat, having a different hairstyle.

re: Refactoring private methods is like...?

Helen — Tue, 15 Jan 2008 20:06:05 GMT

Changing a private method is like redecorating your house. Changing a public method is like pulling down the walls.

re: Refactoring private methods is like...?

Alex McMahon — Mon, 14 Jan 2008 09:36:21 GMT

I think it is important that the analogy portray the importance of contracts.

So changing a public method is like changing your contract/SLA with a supplier, e.g. Time from order to delivery must be less than 3 days.

Whereas changing a private method is like being overly interested in how the supplier meets that contract, e.g. Trying to make the delivery driver go a particular route to the delivery location.

re: Refactoring private methods is like...?

Steven Kelly — Mon, 14 Jan 2008 09:16:40 GMT

Maybe you're in danger of seeing things from the perspective of an author not a reader? An analogy tries to explain a situation unfamiliar to the audience by comparing it to a situation they are familiar with. For you, the topic of writing is obviously relevant and familiar, but probably not so much for the readers. They're already more familiar with refactoring than writing. Actually, your analogy might be turned round to become a great way to explain good writing practices to software developers!

One way to look at the public/private difference, at least when it involves method name changes, is that refactoring a public method is like changing your phone number, whereas refactoring a private method is like changing your phone. Or then moving house vs. redecorating.

re: Refactoring private methods is like...?

Neal Blomfield — Sun, 13 Jan 2008 19:28:17 GMT

Refactoring a public method is like changing your shirt - everyone who can see you can see you have changed your shirt.

Refactoring a private method is like changing your underwear - you know you have done it, no-one else does (hopefully!).

re: Refactoring private methods is like...?

Michael Dorfman — Sun, 13 Jan 2008 13:46:28 GMT

I was going to say that refactoring a private method is like redecorating your house, and changing a public method is like repaving the sidewalk in front of your house-- but I think the grocery store analogy suggested by Andy Sherwood above is probably better.

re: Refactoring private methods is like...?

Kyralessa — Sun, 13 Jan 2008 00:59:14 GMT

I like the name analogy above. Refactoring private methods is like telling someone to call you by your nickname; refactoring public methods is like legally changing your name.

Still, why is an analogy needed? Is it really that difficult a concept?

re: Refactoring private methods is like...?

Addy Santo — Sun, 13 Jan 2008 00:35:56 GMT

Yeah, the car analogy work better (who cares about chapter titles anyway, other than the author?)

Changing a private method is like rearranging something in the engine or the chassis; changing a public method is like rearranging the dashboard or pedals.