Unit Testing, Agile Development, Leadership & .NET - By Roy Osherove
I think that private methods define a contract within the class. public methods define a contract for all users of that class. private methods still define a contract. It's just with a different party.
Changing public methods is like a new paint job on your car, changing the wheel arches or adding a spoiler.
Changing private methods is fitting it out with a turbocharger, bucket seats and a roll cage.
I'm not sure I like that comparison, because there are no consequences for changing the chapter of a book. When's the last time someone didn't buy a book because of the name of a single chapter? Might want to get across that changing the name of a public method is a pretty big deal. Something more along the lines of:
Renaming a public method is like a married woman getting divorced.
Renaming a private method is like a kid deciding to go by his nickname.
I think a grocery store analogy rings a little more true...
In a way, changing a *private* method is like rearranging the shelves in the stock room of a grocery store. Shoppers won't see the change, but the store may run more efficiently for it. I pick up the bread at the front of the store, then the cheese in the back - but I'll never know that the bread is now stored closer to the stock room door.
Changing a *public* method is like rearranging the shelves in the front of the store. You are potentially affecting the shopper who goes looking for an item. I can still pick up the bread first and then the cheese but because of the new layout, it might be more efficient for me (the shopper) to pick up the cheese and THEN the bread.
Either way, I still leave with bread and cheese.
I think it's a somewhat forced analogy. One I like is that changing a public method is like changing from a VCR to a DVD player, but changing a private method is like changing a motor in the existing VCR. Something like that.
Well think in terms of componentization and physical interfaces.
For example, the analogy of the lock. Changing a private method is like changing the lock type from spring loaded to dead bolt. Your same key works fine.
Changing a public method is like changing a key operated lock to a padlock. What a pain for everyone who had the old key.
In terms of cars, changing a public method is like changing a car from automatic to stick, wherease changing a private method is like swapping out the engine.
What's the context? I don't see any relation at all, because:
- As a client of a book, I have to read it all to get the complete experience.
- While as a client to a class, I get the experience by calling a public method, and that experience will not change when the internals are refactored.
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.
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!).
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.
Changing a private method is like redecorating your house. Changing a public method is like pulling down the walls.
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.
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.
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.