Mike hits the nail on the head with this one, while thinking about mock objects.

Rule 2 is especially interesting, because mock testing forces you to think of your code as an API - as you now have two 'clients' (your other code, and your tests). I think in the end it will lead to a much nicer architecture.

I think this is the absolutely #1 reason there is so much crappy code in the world. Folks, for some reason, view APIs as being in the realm of frameworks, libraries and other infrastructure, where it's not something to consider while writing an application. Though, we must not forget that the public, protected, private and in java's case, the wacky no keyword, but package protected all force us to think of several different APIs.

private The API used only within your class. It can be a very informal API, as as wicked as it may be, absolutely no one else has to suffer it. Feel free to live in your own filth.

package protected You're opening yourself up and telling your close friends some of your darkest secrets. These are things you don't necessarily want to whole world to know, but you should at least make them presentable to others.

protected This one is a bit weird. You're still sharing with your friends, but now, any moron who walks up and decides that you are his god has certain access to you.

public Most of the world cares about this, and you don't want to frighten, confuse or scare them. Simplicity is good. Interfaces, interfaces, interfaces.

Anyhow, yes, I agree, Mike. People who don't really consider their classes to be ultra-small APIs even to be used by other classes in the same package, they are basically just writing (possibly poor) procedural code glommed onto an object.

Ick.