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.
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.