3 Simple Rules To Good Object Oriented Code

Mike and I had a long discussion about BDD last night. After he complained about how BDD didn't lead him to the solution he wanted, I said something to the effect of "You know, the only reason we have all these design methodologies is because we don't really know how to think OOP and write OOP".

At this point, before I continue, I need make something clear: I don't know what I'm talking about; all I know about BDD is what Wikipedia says about it. But I do know that writing good OO code doesn't require 3 different methodologies. All it requires if for programmers to think like objects.

I like to think that good OO comes down to 3 simple rules:

1. Objects are all about behavior; not attributes. If attributes defined objects, a cat and a dog would pretty much be the same thing since they both have eyes, noses, legs, etc.
2. Objects are discrete things from which you can build other things. They're a lot like LEGO blocks. Incidentally, code reuse is a byproduct of good OO code, not the purpose of it.
3. Objects like to be autonomous self directed entities. Objects don't like "managers"; if your code has lots of managers, you're probably doing something wrong. Objects like to coordinate their work through events; they don't like managers telling them exactly what to do at every point.

A bonus rule: Composition is usually better than inheritance; it gives you a lot more flexibility when having to change behavior.

To be honest: I'm mostly writing this because I'd like to hear from others what guiding principles you should have in your head when coding. Do we really need a lot of process if we just in our guts know how to write OO code?