Refactoring private methods is like...?
Historical article · Originally published January 12, 2008; technical details may be outdated.
I'm still struggling away with my book, and was wondering what you thought about this analogy.
I am referring to the problem of testing private\public method, and in that regard I refer to the ease of changeability of private vs. public methods and the contracts they assume of the interacting party (reader\developer\code)
Refactoring methods is like refactoring a book chapter.
In a way, changing a private method is like changing a few sentences in a book chapter. The full chapter still may read exactly the same, but the way it is being delivered may change.
Changing a public method is like changing the chapter’s title I the book. You really want to make sure that you’re not hurting the overall feel and content of the reader.
It feels OK to me, perhaps a bit contrived, but what do you think? what is refactoring private\public methods analogous to?