ISerializable - Roy Osherove's Blog

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 don't think that's a great analogy. It's not related to how "big" the change is. They key point is that changing a public method is visible to the consumer of the class. The private change is not.

Besides, don't you know that all tech analogies are supposed to be automotive?

Changing a private method is like working on the engine, changing the oil filter or installing a turbo. It all looks the same to the driver and they don't have to change the way they use the car.

Changing a public method is like installing a new radio or a child seat. It's visible to the driver, and changes the way they interact with the car. They may also have to adjust their plans for using the car -- they won't be able to drive three friends to lunch any more with the child seat installed.

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.

Maybe an analogy that conveys the hidden nature of private methods would be more useful, something like a Gear Stick/ Transmission analogy, where the end-user of a car has only access to the gear stick but the mechanic can delve into the inner workings of the transmission and change/refactor parts of it without affecting the gear stick. That would convey the aggregated and inmediately innaccessible nature of the relation between private/public as well as their dependency, were in the book chapter analogy everything is inmediately visible and it feels more like the relationship between a method signature and a method body.

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.

Roy Osherove is looking for some help on his book on how to explain the ease of changeability of private

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.

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?

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.

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

=)

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.

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.